Matt’s Docker Orchestration 1.0

 

My ECS (EC2 Container Service) alternative is complete. 🙂

I ended up creating the server portion of the AWS tutorial using a very simple sort of manual Docker orchestration. Long story short, run your Docker containers with “–restart always”. This tells the Docker daemon to automatically restart the containers in the event of a crash, and (and this is key), it tells the Docker daemon to automatically start the containers when the daemon itself is started by the operating system. And when does that happen? At boot.

So with that one little switch added to your “docker run” command, you’ve got something that will just keep going, and going…

Energizer_Bunny.png

To make things simple for the users, we provide a script that runs the Docker commands appropriately. The user never has to actually enter a Docker command to set up Rutilus on AWS. They create the instance through the website, SSH in, and run my setup script, which finishes setting up the instance, installs Docker, pulls from our Git repo, builds the Docker images using the latest NPM modules for the Rutilus modules, and runs the Docker containers.

And for our purposes for Rutilus, at least in the scope of Engineering.com’s implementation of it, it works. It can’t scale (it just restarts the containers, it doesn’t launch more than one of them). It can’t do fancy things like sending one container to one EC2 instance and another container to another, like ECS can. But Engineering.com doesn’t need something so massively scalable. We don’t need to get tons of AWS permissions to encompass the ECS service, just EC2 permissions are fine. And telling them how to maintain it is as simple as “If you want to stop it, just SSH in and run ‘docker stop’. Run the tutorial’s massive script that sets it up for you again to start it up again.”

Of course the process of getting to this wasn’t as simple as the end solution. I had to experiment with startup scripts (I originally thought –restart always didn’t take care of everything we needed) and permissions, and making my start up script I thought I needed executable, and worrying about whether or not the future versions of the AMI would support the startup method I chose… But I’m happy I went through that process. It ends up simplifying our project and making it less tightly coupled to AWS. In theory, because this just pure Docker, the open source community can host our app with that setup script from the tutorial on any IaaS cloud host.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s