Exploring Dockerfiles

I’d like to continue the previous entry on Docker a little further. Last time we talked about the installation process & a little more, so this time we’re going to talk about the next part of getting started with Docker – writing a Dockerfile.

Here’s what we talked about last time, and with one odd little exception (why did I promise to talk about load testing…) we’re going to cover all these things!

So, next steps, make the container persistent – it isn’t yet, and play around with Dockerfiles, and just do a little more spying on the produced container itself & probably try to do some babby’s frist load testing things in there & spy on the container as a process without the box & all its processes within!

First let’s take a look at the Docker process we created last time. Just like at your native command line, docker commands all resemble low-level Linux commands, so just like you’d use ps to look at the processes running at any given time on your machine, you can use docker ps to see all the Docker processes it is managing at any given time. If you followed along last time you’ll see some that have been exited but which you don’t have access to – each time you run the docker run -it bash you get a new process. But the old ones are still there! The all flag will show us these Exited boxes with a docker ps -a.

rachel $ docker ps -a
CONTAINER ID        IMAGE                      COMMAND                  CREATED             STATUS                     PORTS               NAMES
b5de9583d7b3        fedora                     "bash"                   10 minutes ago      Exited (0) 3 seconds ago                       pedantic_morse
35192bfa05d4        images/cowsay-dockerfile   "/usr/games/cowsay *P"   2 hours ago         Exited (0) 2 hours ago                         gigantic_goldberg
a0e40d55125a        images/cowsayimage         "/usr/games/cowsay 'D"   3 hours ago         Exited (0) 3 hours ago                         jovial_mcnulty
d32381833772        debian                     "bash"                   3 hours ago         Exited (0) 3 hours ago                         cowsay

You’ll notice a few things, first that the names are a mix of adjective_noun, except one – the cowsay container example is from the excellent Using Docker where I’ve gained a lot of my recent Docker information. Their status is all Exited. Some of the container-specific commands are similar to the init.d service commands, like start, stop, and rm, so let’s start the desired container in that list up there. The container we’re going to start up is similar to the one we made before & is Fedora, though it is true that I only made it ~10m ago!

docker start pedantic_morse

So now the output of docker ps includes the container we just made. So how do we keep it? We commit it, just like with Git! Replace pedantic_morse with whatever name yours has been assigned beneath the NAMES column.

rachel $ docker commit pedantic_morse images/morse

So what we’ve done here is create an image from which we can create containers. images/morse is the image, pedantic_morse is the Docker process that we crafted it from. For every time we run the image images/morse, it creates a new Docker process, so at this point it’s still not persistent in ONE image, HOWEVER we can use this image to perform one-offs.

Clearly we’re not getting into the strength of Docker, yet. So now it’s time for a very basic Dockerfile. Just like Vagrantfile and Procfile & probably a few other similarly intended setup files, the D in Dockerfile is capitalized and there’s no extension to it, because remember – Linux doesn’t care about file extensions!

The main piece to know with Dockerfiles is that their syntax can be as minimal as you like, and personally I recommend making them non-complex – major structural pieces, and insert kickoff scripts or use some config management in the container itself for anything much more complicated. I reserve the right to change my mind on this later! And this is also more for next time to learn. But the way it looks, the RUN command will run any bash you put in it, but if you need anything more complex, the contents become a lot more murky, in my opinion. Simple is better than complex, but complex is better than complicated, so let’s do what we need to here.

For posterity and a simplistic example, here’s the first Dockerfile I ever wrote. (ed note: I trimmed this down because each line of a Dockerfile creates a new filesystem – try to truncate Dockerfile lines as much as possible)

FROM fedora:23
RUN /bin/bash
RUN echo "the dockerfile took!"

RUN dnf install -y wget tar man


The output of this, which is a bit long to post, pulls down version 23 of Fedora, uses bash for the following commands, prints “the dockerfile took!” to stdout, and then installs those three packages. I’m unsure why some of those aren’t present in a base Fedora image, but it doesn’t appear to be related to what I’m working on in this blog post, so we’ll leave it be for now.

This is about ten times longer than I thought it would be, woohoo! I hope you learned something, please please let me know if I’ve missed the mark on anything, cheers!

Tune in next time and we’ll talk about a more complicated Dockerfile, and syncing it up to… something 🙂 come back and you’ll find out what!


Employment and Education

Hello friends! TIME HAS PASSED. But here you are again! This day finds me employed, after a long struggle. Really, I’ve been job-seeking since January, though well in advance of when I needed to, as my graduation date was March of this year. Believe me, I am still fuzzily post-graduation, extremely happy to have no far less homework than while earning my degree (en français, bien sûr !).

Understanding that confirmation bias makes fools of us all, about two months ago I changed my resume (do I write résumé? seems soooo new yorker snobbish, though it is correct) in what may have been a crucial way. My tech recruiter friend gave me some terrific and honest (read: intense) feedback on my R/CL and told me to cut out the “References available upon request” line, because duh, everybody knows that and it just takes up space. For a few weeks, I had it removed entirely. Then, I did something rather bold, and added the following snake-oil-style pitch toward the bottom of my cover letter:

“But don’t take my word for it! Just ask person_1, the leader of the free world, or person_2, the founder of Mars, or even person_3, the inventor of Post-Its! Every one of these folks is happy to -brag about- be a reference for me, so please, contact them!”

And I got a call, from an awesome company that I have always been too afraid of applying to, thinking that the folks that work there are a special kind of brilliant & that I wouldn’t have a chance in hell at actually working there. One of the reasons, other than my qualifications, that they said they called, was because of one of those people who I’d listed in that section.

Typically, references are a very late game process in the hiring world. Why bother calling references, a time-consuming and very personal (and personalizing!) process, if your candidate hasn’t even made it through a phone screen and an interview or two? In other words – why call references unless everybody is serious? But the fact that I put a few folks on there who wanted to vouch for me made a huge difference. And Portland is really so small and the scene is so focused that the names are fairly well-known. That wasn’t an accident, but I met these great people naturally, by getting out, participating quite heavily (and earnestly!) in PyLadies, and making friends with the people around me.

After two phone interviews, a task, an all-day interview, and a few (totally transparent!) hiccups, I was offered the job at Puppet Labs as a support engineer, and I feel so lucky, I have to keep from gushing about it. I left my stable, lifer career nearly four years ago to do ambiguously Better, and yes, Virginia, this is Better.

SO! Now I am LEARNING, learning learning learning! I’m still having a hard time reading the tickets that come in, but what I am able to do is parse Puppet code, and explain what it is and does, and how it’s an enormous, Neil Armstrong-style leap over previous (and still very widely used!) server management technologies. I’m pretty sure I’m in the right industry, guys, as this is really cool to me. Puppet is a company I am extremely excited to work for, for many reasons, not the least of which is getting to know the complex, technical, and awesome product. I keep a notebook on what I’m learning, and I fill several pages a day. Future blog posts will probably just focus on Puppet stuff, unless I get a chance to work on some recreational stuff. Woo-hoo!

And one last thing: if you know me, you know my absolute most highly recommended piece of advice to those looking for jobs: start a blog. Start a blog, start a blog, start a blog. Don’t wait til you code every bit by hand, don’t wait til everything is Perfect, just go to wordpress or blogspot or whatever, and start a blog. Nearly everyone I’ve interviewed with has mentioned it. Fear not about seeming stupid, because you’re brilliant.

Ok – going to cut this off before I get weepy/proselytizey/we-are-the-world-y. GOOD THING.

Javascript first thoughts, mackatoots, & tutorialino

Hello again! I have been working and working and working, lately, and I have a few things up my sleeve!

First, my company, The Open Bastion, is working on tutorials in Python. Get in touch if you’d like to create with us! Note: paying gig 🙂

Next, though I know some Python, it seems that I need to keep going, so I am learning Javascript, now. Exciting! Something altogether new! So far, it seems like a friendyfriendly C analogue, based on the 50-odd pages of a C++ book I read back in the day, which makes web site and app creation a BREEZE. I know complications will come – I feel like I hear more complaints about Javascript than any other language, right now, but as with all new languages, I’m really enjoying learning the syntax. I’m doing the Codecademy interactive tutorial and it’s adorable and fast fast fast, so I feel like I am getting a lot done and learning learning! Note to self (and to youuuu!) to research later – why are semicolons sometimes required at the ends of lines & sometimes not? I wonder – is it more than just good style? With Cx semicolons are quite explicitly required, right?

Next, I’m working on a Mac, now. If you know me, you’ll know that this is, like, a huge deal for me. It’s just a work machine, AND it’s four years old, buuuuut it’s great for coding even if it’s comically bad at other things, i.e. file management (honestly does anybody EFFECTIVELY use Finder? my theory is that apple wanted to ensure that their file management system was different than windows’ [whose Explorer {directories, not internet} is superior to all others] and now they’re too bashful to back out???). The mouse pad, though, is a serious delight to use, the best touch pad I have ever operated on, and the keys are lovely to type on. It’s strange having no optical drive (it’s an Air) and the minimal number of USB ports can be frustrating, but of course, a $1300 machine is a $1300 machine, and a professional versus hobbyist (read: my perfectly delightful $600 2.5y/o windows/ubuntu machine) computer is going to be a vastly different user experience. I hate the fanboyism around macintoshes so, so much, though, that I probably will still never buy one on my own, but it seems you need to be comfortable with them to work in tech, at least in Portland. So here I am. A bit blech, a bit “oh this works really well.”

Lastly, I’m volunteering with a group called Chick Tech right now, which assigns mentors in industry to young women. It’s a very cool organization, and I can already see myself staying involved with them for a long time. I worry about this approach to solving one of tech’s many diversity problems, though – the problem, at this point, is not to interest young women in STEM, but to keep grown, adult women in tech once we are here. And here, we are, and I/we will demand equality. Jessica McKellar and Selena Deckelmann, a couple of fabulous tech luminaries whom I follow, both refer to the “leaky pipeline*,” – we can get them in, but we can’t keep them there. I think the following tweet from Jenny Thurman sums up the issue quite well.

So I will continue to think about this while I have a blast with my mentee, a motivated young lady whose trajectory I am excited to follow and encourage.

* the earliest reference I have found to this particular use of this term is from a paper from 1996, found here.

Heroku Hero Haiku

Heroku Haiku
Are not easy to write, no :
You can tell by lame.

Ok, that might be a bit of a stretch, but I think it’s an appropriately silly start to my Heroku knowledge! Today, I will learn to use Heroku, a platform-as-a-service (PaaS) cloud application that, as far as I can tell so far, acts as a sort of auxiliary server for development.

I am going to start on the quickstart and then moved on to the headier document entitled How Heroku Works. I’ll be documenting my process in this entry, so, stay tuned! (I’m talking to YOU, happy-hour-free loner out there!)

Update 1:

Ok, first update, I’m finally putting git onto my machine. It was (or at least seemed) awkward on windows, since the command line is just a whole other beast over there, so now I’ve got it on the linux end. fabulous; all I did was type git into bash & it said “if you want to download this just type sudo apt-get git” and that is so amazingly helpfully easy. I think this will be a whole new reason to use github, which I haven’t been doing for a while because I’ve been so into the CLI lately and I only ever used github’s browser interface. Progress, of a type!

And now I’m trying to flash-dash convert a python program I wrote in 3.3 to 2.7! raw_input is weird! ok, a half hour later & I’ve got that locked down, the differences between which you can see at its github repository.

Update 2:

And now I’ve got the heroku toolbelt for linux on the machine, here. Why why why does it seem so much more approachable on linux? Why is the scrolling text of installation so very comforting to me? Why, indeed, is the sky blue. I actually did the boneheaded thing of accidentally typing my master pw in with capslock on, really! so that is a funny/dumb thing for me to have to remember. [edit: since fixed] and with my successfully converted python 2.7 program, which I have cloned to my system via the heroku dashboard helpful page, I’m now on the git push heroku master, the entire logistics of which I am as yet unsure.

Ah crum. it went through the git push heroku master, counting objects, compressing them, writing them, and THEN it has said

Push rejected, no Cedar-supported app detected
To git@heroku.com:stormy-scrubland-8935.git
! [remote rejected] master -> master (pre-receive hook declined)
error: failed to push some refs to 'git@heroku.com:stormy-scrubland-8935.git'

but doing the heroku open still worked just fine. I do not know what cedar nor “stormy-scrubland” mean, though I’m guessing the latter is some kind of version of cedar, or some version of heroku. it seems like that kind of cute hacker convention in line with “llooming llama ubuntu” or whatever the L was called, ha ha! edit: ok, weird. stormy-scrubland-8935 is the name of my app on heroku? somehow? that’s an odd name generator. [edit: I think that this is because I did not create a heroku environment before pushing the git change, with a quick heroku create beforehand.]

Update 3:

Now I’ll be installing Flask, required on the Getting Started [in heroku] With Python page. It says to have pip, virtualenv, and of course, python installed in advance. I have already installed these items, so that is fortunate. Now, I’ve activated the virtual environment (venv), and while I’m glad to know that I can’t borf (borf is a VERY technical term) my computer irrevocably while within the virtual env, I am Worried that I have already done so, & that with any programming & new set of tools to download, I should have already been putting it all in a virtual environment. BLAST. ok, now I need to find out if my entire environment is salvageable, haha! I have heard about this linux problem, that is to say, when you start a new project but instead end up necessitating a machine-wide wipe and OS reinstall. Oh jeez. Ok!

And now I’ve figured out virtualenv. It was giving me tons of crazy errors, like “nothing in “*”” which means that there was nothing in the indicated path, as that’s what the asterisk means, and also “nothing of *.pyo” and “nothing of *.pyc” which are python compiler file extensions, so I got out of the virtualenv I’d made above & deleted it, and started over using virtualenv venv --distribute --no-site-packages. then it worked! now, whenever I’m screwing around with any programming, I know how to create a virtualenv and I won’t (further) irrevocably borf (still a very technical term) my machine!!

FINAL Update: WOW! What a terrific exercise. Many hiccoughs along the road, but now, at the end, I have learned so so much. For example, now I can tell you what Heroku really does – it’s something that will take in and run your program, but is separate from actual domain/web hosting. Though the tutorial does host it on heroku, it’s obviously intended for your own site, ha ha! Also, I’m now totally comfortable with virtualenv, which is a really crucial step for me. There’s more, but I’ll reserve it for a future update! Thank you for reading this megapost!

brb trying to install django

wish me luck!

EDIT: so. this installation has been Really Hard. finally, having installed wsig, virtualenv, and virtualenvwrapper, I finally installed pip to handle python-related downloads, and while muddling yet again (really – for like the tenth time over the last couple days) through trying to just download django, my friend suggested, “well, why not just sudo pip install django?” HA! beautiful! so that worked, immediately, and now I have django on my linux box. woo-hoo!

now to USE it, to make a django-structured (probably wrong terminology) personal site, to showcase my ~tAlEnTs~! aaaahhhh