Use Containers for Development - Day 1

Jul 1, 2019

Regardless of where your code runs, there are benefits to using containers during the development process itself. You might think you need a development VM, or that you are on a Mac, and you know the runtime will be Linux and consistency would help. Or all the modules or libraries or tools that you install will conflict with the versions on your laptop, or that you will lose track of all the stuff you installed when it comes time to take another step towards production.

Getting you feet on the ground with using Docker simply as a development environment should not take more than a few hours, but if you are like me, you have only random slices of time to think about or work with unfamiliar tools. The intent here is to give you a little slice towards the whole pie.

Step zero is to install Podman (or Docker CE). The two are roughly interchangeable, so either will do. If you are using Podamn, create a symlink so that you can use others’ docker-based examples transparently.

On macOS…

brew cask install podman

On RHEL8, Podman is available be default…

sudo yum module enable -y container-tools:1.0
sudo yum module install -y container-tools:1.0

For other platforms look here.

Start an example centOS host the verbose way…

docker run –interactive –tty –rm –name cent centos bash

…or the short way…

docker run -it –rm -n cent centos bash

You will drop into a root shell of a container instance. Prove it to yourself with…

yum install git

Anything you do in this environment will disappear entirely when you exit. That may seem to make this config far less useful, but not only is it useful, it encourages some good practices and you can change that behavior if you need.

Principles that this practice encourages:

• The server/vm/container you are using does not matter, and should be thought of as disposable. [ Ephemeral Infrastructure ]

• The server/vm/container you are using does should not even be changed. In fact, it is better if it is a read-only environment when it goes to production. [ Immutable Architecture ]

Also…

• You can still bring data and config in, write it to databases externally, remote syslog, etc., even if you treat the environment as ephemeral.

• You can run it as a persistent container that can be started and stopped. Not a big deal during development, but the closer to prod, the more beneficial it gets.

If everything is smooth up to that point, you have a sandbox to play with.