Registries and backups for docker containers

There was a recent tech podcast in which one of the guests explained that he was turning his back on certifications.  When asked how he will provide proof of his knowledge, he stated that he would present his portfolio.  That included Github, a blog, and presumably Dockerhub.  This approach is not realistic for everyone.  Sometimes maintaining a cert is a condition of employment.  But, the portfolio will probably start to become a standard practice when going for anything beyond an entry level position in the development world.

The shining star of Information Assurance is usually security, but backups are also a critical part of IA.  In practice, the backups allow for a stronger security posture.  I've had to roll back to a previous image of a virtual machine because some security setting was implemented incorrectly and fried a machine.  Modern devops should be starting with a secure by default image and then loosening security to allow an application to work.  This might mean that you have to roll back to an image that is more secure because loosening a control did not resolve the broken application.

We'll start with backups and move to repositories to create a decent development environment.  I am aware that there are tools that allow you to jump into a shell on a container, modify it, commit those changes, and push it to a repo from a single screen.  That's great if you intend on really going crazy with development.  I'm not going to implement those tools, because they will not be necessary for basic modifications or testing with a low volume of containers. 

From the build your own container blog, we should know how to get into a shell on a container with docker exec.  Once there, you make your modifications and add programs to build a container application.  Now, you've put in the time, but it isn't working exactly the way you want.  Time to hit pause and think about what it might be missing or what needs to be configured for it to work.  You need to commit the changes and you should probably save it. 

Aggregate 1
Commit!     

Commit will allow you to give a nice tag to the container and allow you to spin up that version to keep working.  But, you may want to take it to a new machine (like a laptop) and work on it elsewhere.  That's when you need to save it. 

Aggregate 2
Save! 

And once it is moved to the new host, you will need to load it to continue working.

Aggregate 3
Load!

Yes, all of the aggregates will come from Docker.  But I promise, this is just to explain how it should flow.  What has been described so far is a single person development environment.  Nothing has been pushed to a repo.  For a home user, you push to a private repo for collaboration, and a public repo for actual deployment.  This is also where things branch out.  Either you can figure out how to get the application configured, or you hit a bump.  If you hit a bump and need someone to look in the container, you can either share the tarball for the saved application or you can push it to a private repo and allow access to people that want to collaborate. 

The access controls for making a repository private are dead simple.  There should be a giant "make private" button in one of the menus.  It's not very intuitive to add users for collaboration.  Just remember, development containers stay private.  Production containers need to be cleaned, tested, and evaluated before pushing to a public repo.  The access controls should be locked down completely for a production repo, only one account should be allowed to push to it. 

I prefer using Dockerhub, but there are also instructions for private repositories in the instructions.

Aggregate 4
Login before you push 

I would also recommend using one of the keystores mentioned in the login instructions.  I don't think anyone will be sifting through my bash history, but it's a good practice not to use a password in the CLI.  You then tag and push.  My experience with Dockerhub has been that it is default in these commands, so you do not need to specify the repo in the command.  My login, tag, and push look like this:

docker login -u dockerhubusername -p dockerhubpassword
docker tag local/container:version dockerhubusername/container:version
docker push dockerhubusername/container:version

The instructions listed in the following aggregate are a bit more universal, so they include adding the repo to the commands.

Aggregate 5
Tag and Push

You can then verify by looking at your Dockerhub account and running the docker images command. 

Never forget to clean up your container before pushing it to public.