Leveraging Private Dev Containers

Leveraging Private Dev Containers

So this should be a pretty quick post, but I thought I would share this tip and trick I found while playing around with the implementation.

Dev Containers really are an amazing advancement in the development tools that are out there. Gone are the days of being handed a massive document and spending a day or two configuring your local development machine.

Dev containers make it easy to leverage docker to spin up and do development inside a container, and then putting that container reference into your repo to be rendered.

Now, the problem becomes, what if you have private python packages or specific internal tools that you want to include in your dev container? What can you do to make it easier to developer to leverage?

The answer is, you can host a container image on a registry that is private and exposed to your developers via their azure subscription. The benefit to this is it makes it easy to standardize the dev environment with internal tools, and make it easy to spin up new environments without issue.

So the question becomes “How?” And the answer is a pretty basic one. If you follow the spec defined here, then you will see in the devcontainer spec for the json file, there is an initializeCommand option, which allows you to specify a bash script to run during the initialization of the container.

But inside that script, you can add the following commands to make sure your dev container works:

az login --use-device-code
az acr login --name {your registry name}
docker pull {repository/imagename}:latest

And then when you build the DockerFile, you just point to your private registry. This means that whenever your team is able to start up their dev container, they will get a login prompt to enter the code, and log into the private docker registry. And that’s it!

Leave a Reply

Your email address will not be published.