Developing inside a Container

In Container development even in an OFFLINE environment

5 min readMay 1, 2022

In this article, I will walk you through the process of enabling the magnificent feature of VSCode, in container Development, in an offline environment.

But first, some background, hope you already know what is docker container, why you should use it, and how to work with containers.
For extra clarification, in one sentence,
container is an application unit that contains only the necessary staff for the app to run. With separation from the machine and the operating system.

So, what is Developing inside a Container

Developing inside a Container lets you create a container that contains all the application requirements and then develop inside this container.

That means that you can create a specific development environment for every application that will match your production environment as easily as possible regardless of your working station.

For instance, let’s say your team develops a NodeJS application that in the production environment runs on alpine linux3.10 with NodeJS 12. But your PC is running on windows and already uses NodeJS 14 as a dependency for some other apps.

The easy solution is to build a docker image that contains alpine linux3.10 with NodeJS 12 and your app artifact and run it from your PC.
With this solution there are some issues, working containers come with some bottlenecks when each change requires you to build and run the image again (instead of using it as you would in a local run, even with hot reload), and for debugging it is even harder because you need to attach to process in order to debug your code.

Developing inside a container is a better solution because you are working as you would work if you run the application regularly in your working station.

How it works

developing inside a container architecture

VSCode will create your development container and run it as your devcontainer.json file describe and connect your source code folder as volume mounted to the container.

The devcontainer.json is the config file for your development container. In it, you can config the container Dockerfile path, env vars, etc.

With the volume mount, you will be able to use the folder as you like from the VSCode IDE, but any action you act will activate from inside the container. Such as open integrated terminal, the terminal window will open inside the container and every command there will run inside the container (like using docker exec).

Requirements for using in container development:

· Docker desktop on your machine
· VSCode
· Remote — container extension
· Remote — SSH extension

After installing the extensions, the green button on the right-left will appear and this button opens the remote container actions menu.

So,

· your source code folder is already inside the container as a volume mount
· your dependencies platforms, operating system, and ENV vars already in the container using the devcontainer.json config or the container image Dockerfile config.
· And you can run commands inside the container easily.

Let’s take the NodeJS 12 application example from earlier again,
you have created a dev container that contains alpine linux3.10 with NodeJS 12 using devcontainer.json config that describes exactly that.

{
“name”: “devContainerConfig”,
“image”: “node:12-alpine”,
“settings”: {},
“extensions”: [],
}

After you click the option to open the folder in a container, all we are left to do is to run npm start from VSCode integrated terminal.

Wait that’s not all, there is a catch.

Many developers work in an offline environment, without an internet connection, as a result of working in a government department or as a result of network security policy in the organization.

The developing inside a container feature works only when you have an internet connection and that’s because in the container creation process, the container download VSCode-server, for communication between VSCode and the container, and all the extensions.

In case you tried to use the extension and it failed you may see that the error pointed to the failed fetch request to update.code.visualstudio.com that was supposed to bring the VSCode-server.

If you would like to use this feature but to use an offline environment, it’s possible with some workaround.

How to make it work offline:

· Enable “remote.SSH.localServerDownload”: “always”
in your VSCode settings

· Check your VSCode commitID — it’s your VSCode version id
help -> about -> commit

· Download the VSCode-server that compatible with your VSCode
from https://update.code.visualstudio.com/commit:[COMMIT_ID]/server-linux-x64/stable

· Extract the file compressed file

· And insert the folder into your container
you can do so by adding the copy command to your Dockerfile
COPY [./vscode-server-1.66.1] ~/.vscode-server/bin/[COMMIT_ID]

And now it is supposed to work fine, and you can start developing inside a containers.

If you still have problems, check if the container has the vscode-server in the right path and that you use the correct COMMIT_ID.
This solution is problematic and not recommended unless you don’t have any other option to use the remote container feature. This is a great feature for easy managing different working environments for different apps.

By the way, if you are developing in a semi offline environment, just set the “localServerDownload” config variable to “always”, create the container in an online environment, and then it will work fine also in an offline environment.

In conclusion

Why you should use it:

· Easy managing application’s working environment.
· Developing on prod specs environment without any “magics” (env vars, libraries, etc already on your pc).
· No need of preparing the development environment anymore…

Why you shouldn’t use it:

· Not straightforward workaround
· You have to update the VSCode-server each time you update your VSCode.

I think that developing inside a container is a great feature that brings the way of managing your working environments to a whole new level. For new developers with no need of preparing the working environment, and for developers that work on multiple projects with conflict dependencies.