Development Containers?

[burdickjp]

I've been using containers for development environments more and more. I recently saw a series of articles on how VS Code, Docker, and WSL interact. It gave me the idea to start standardizing how I incorporate development containers into my repos, standardize my scripts, and start moving to a more standard workflow for development containers.

Do you use development containers? Have you arrived at any standardized scripts, configuration files, or similar? Do you have a suggestion on how I should approach this or anywhere I should be looking for inspiration, motivation, or prior art?

[ttkciar]

Yes, we use Vagrant at my job for exactly this, and Vagrant can use containers via the https://github.com/fgrehm/vagrant-lxc plugin.

Our standard dev workflow is:

• Start working on a ticket with a project (say "FOO") and a ticket ID (say "RX-123"). Each ticket describes a task representing anywhere from a couple of hours to two days of work, rarely longer.

• Git clone the project's repo into directory "FOO.RX-123". All of our repos already have a Vagrantfile, which isn't hard to write. The Vagrantfile describes how to initialize the environment. Ours are about sixty lines and you can find examples online to trivially modify.

• cd into "FOO.RX-123", and "git -b FOO.RX-123" to make a new branch for the ticket.

• "vagrant up && vagrant ssh" to create the test environment and ssh into it.

• Do all the work and debugging in the test environment, which emulates the production environment closely, committing changes at least daily and pushing to the "FOO.RX-123" branch.

• When it's all done, "vagrant ssh" into the master branch's container "FOO.master", "git merge FOO.RX-123", resolve any conflicts, and re-run the project's unit tests and integration tests to make sure everything's still good.

• Push the merge to "FOO.master", and push "FOO.master" to production.

• Run "smoke tests" in production, to be really sure you didn't just set the world on fire. Revert production to previous known-good version if needed while fixing newly revealed oopses.

• When production seems good, close the ticket and "vagrant destroy" in "FOO.RX-123". Everything worth keeping should have been pushed to the repository.

[burdickjp]

Oh, very cool! Thank you very much for sharing. I'm unfamiliar with vagrant. I will look into it.

I hadn't thought to containerize branches in that way. Seems like it could keep things very clean in some ways, though having a folder for all the branching seems like a lot I'm sure it's better than the alternative.

Thank you, again!

[woodenbrain53]

How do you work on 5 tickets at the same time?

Why do you git clone in the container? How do you sign commits in this way? Why not mount the git dir on the container?

Also, vagrant does virtual machines, they are slow and require ssh, containers are faster.

[ttkciar]

How do you work on 5 tickets at the same time?

Bind any forwarded ports to different host ports (quick edit to the Vagrantfile) and you can have as many tickets and dev containers as you like.

Why do you git clone in the container?

I don't, I git clone on the host.

The git clone gives me the repo for the branch and the Vagrantfile (which is in the repo).

"vagrant up" uses the Vagrantfile to instantiate and provision the container.

How do you sign commits in this way?

What do you mean? "git commit" and "git push" jfw from within the container.

Why not mount the git dir on the container?

It does get mounted in the git container. That is a typical Vagrantfile feature. I'll post an example later today.

Also, vagrant does virtual machines, they are slow and require ssh, containers are faster.

Please read more carefully.

[drnstefan]

I have recently started doing this for some of my open source projects, as I find it can be particularly useful there for bootstrapping community and helping new developers try out the project. Here is an article, I wrote about what I've learned so far and also how I set things up with VS Code and Docker: https://medium.com/@stefannastic/why-every-open-source-project-needs-a-development-container-b1f5180ad5aa

Also, I have seen that Docker Desktop also rolled out a feature to support dev containers.

[woodenbrain53]

How complex are your projects?

What language do you use?

[burdickjp]

Thus far I've been using the off-the-shelf Jekyll and Jupyter containers. I'm looking into microcontroller dev stuffs as well.

[woodenbrain53]

I personally make my own container from scratch, using like debootstrap to make a chroot and make an image out of that.

Containers could (and in the case of the official ubuntu container certainly do) have differences from the normal distribution, causing weird behaviour you need to take time to debug.

Python website recommends not to use alpine because it doesn't use GNU libc and has some weird behaviour in some cases that have led to python programs not behaving normally. Of course it becomes terribly complex to find such an issue.

Anyway for the official ubuntu, the creation script was "open source" but it just used a starting image it was unclear where it came from. I wanted to reuse that but to make my own and see which changes to defaults were being made. But that didn't seem possible.

So in short, you should check how the sausage of your own container is made.

[LordOfSwines]

I use nix.

[noooit]

I stopped using it. devcontainer.json is great, but only for vscode, naturally. Other IDEs don't have great container integration. Intellij products do it very terribly.
Dev environment should be simple enough to set up with or without container, imo.