Getting Involved with Docker and Containers

Container technology is one of the biggest innovations to the IT world in quite a few years. Ironically, the technology has been around for a very long time - 15, to be exact. In a world were efficiency in servers is king, this almost ancient technology found a way to change the game in a manner similar to virtualization. To quote Adrian Cockroft of Battery Ventures in a recent article from the SD Times, “What virtual machines did was consolidate the CPU power. Docker takes it an extra step because it consolidates the memory….” What we are going to look at today is how you can utilize Docker, and how it can help you. What is great about the technology is that regardless of whether you are using a cloud server or a private, dedicated sever, containers can still work for you.

Docker supports its development community by acting as a hub of services that developers can pull from - so if you need your container image to have MySQL and Apache, you can find a way to get it with ease through the command line prompts. A developer should be aware from the sources that they pull container data from; as they might be pulling data that isn’t fully updated and could be exploited. Docker Containers all share the same host OS, so be sure to check the host for security updates before deploying too deeply. For larger scale deployments of containers (Say, scenarios where you host your own Docker Images which are used by development inside containers), Docker offers many tools to automate container creation and deployment, which is very helpful to support DevOps.

There are a few other best practices to consider - for one, don’t run the container as root if you can avoid it. This will prevent corrupt containers from ruining your host machine, whether it is a VM or a bare metal server. Containers also shouldn’t carry any additional applications that aren’t needed - if an image has LAMP and NGINX, for example, and all you need is LAMP, find a container that just has LAMP. Running extra applications isn’t necessarily going to hurt you, but it will lower the efficiency of your container environment, thus eliminating the point of using Docker: efficiency. On that note, always be sure to check the image that you pull containers from - we said this in the previous paragraph, but it really is that important. Don’t put yourself at risk of a bug like Heartbleed by pulling from an outdated image.

Finally, understand Docker’s command line - much of what makes Docker tick is found in the command line, and if you aren’t comfortable utilizing the command line to some degree, it really isn’t the right tool for you. Some big commands to be aware of are:

Attach - allows you to attach a running container so you can utilize it in your environment. To get rid of the container, you can use the Kill command

PS - lists containers. By default it will show the containers that are currently running

History - shows the history of the image. This is where you would check to see how valid the applications on the container are (ex. If you see that SSH hasn’t been updated since 2014, kill the container because it is asking for trouble).

Push - sends an image to the Docker Hub or to a Hub that you utilize for your own use