VSCode Remote Container: Why A Developer Needs This?
As part of this blog, we are going to understand how we can leverage Docker with VSCode Remote Container to provide a sophisticated development environment tailored to the use for specific software development.
As the development landscape is changing, so are the tools for developers.
What we will cover in this tutorial?
- Problems with the current development status Quo
- What kind of sophistication VSCode Remote Container will offer to developers?
- How is it different from maintaining infra from docker-compose?
Problems with the Current Development Status Quo
- Install Multiple Software/tools for local machine Setup
- Working with multiple Projects
- Parity with Production Environment
- Project OnBoarding Wiki
- It works on my machine problem
- Missing the Estimation
- Learning
Install Multiple Software/tools for local machine Setup
Let’s say one of our back-end projects (like SpringBoot) depends on Postgres DB. The following should be installed on our local machine in order to work.
- Install Postgres DB
- Connect to DB via any GUI tool like PgAdmin, DBViewer, etc. or connect via the pgsql command-line tool
- Import schema or preload data
- Get the DB localhost URL, port and username, and password
- Configure url, port, username, etc. in the SpringBoot application. properties/yml
- Install Java (Correct Version of Java) and set the JAVA_HOME
- Install maven or gradle tools to build the application
- Start the application from the command line or Use Integrated Development Environments (IDEs) such as IntelliJ, VSCode &, etc. to start
Hmm, There are a lot of steps to follow to run this application on the local machine!
What to do if there are additional dependencies such as Redis DB, Node JS, React JS and some shell utilities that require JQ to scan JSON objects. The developer should install the following tools on their computer with the corresponding version numbers,
- Java 11
- Node Latest
- Install Jq tool
- Install Redis DB
It’s a lot of work that needs to be followed by every developer on their local machine to make it work.
Working with multiple Projects
At present, a software system consists of more tools and frameworks. Typically, a web application is built with front-end tools like React, Angular, etc., using the back-end as a Node, SpringBoot, Python, Go, etc. Data stored in the SQL, No-SQL, Key-Value databases. It makes the system more extensible and resilient for end users. But for developers, it is like a tedious work to simulate this system (or part of the system) on the local machine to perform their development.
Parity with Production Environment
For instance, think about a SpringBoot application that connects to the Postgres database for its operations. In the production setup, SpringBoot is set on the production database. But during execution on the local machine, we need to provide Postgres database connection details to be executed on the local machine. Few of us would like to use the H2 database as it does not need much more configuration. But Postgres is not equal to the H2 database. Parity is important if need to simulate similar to production. If we use Postgres in production, it is worthwhile to use Postgres while simulating local development work.
Project OnBoarding Wiki
As a developer, beginning the development of new projects, many of us spent a few days setting up dependent systems or tools. Few teams will have a nice wiki page to understand its dependent systems and documents on how to set it up on the developer machine.
As a team, updating the wiki page (any wiki page) is one of the more difficult parts (or at least for me: -)). Sometimes we can’t add certain configurations (like dependency on Postgres DB) when developing certain features. Some teams will have technical backlogs to review/update wiki pages (at integration wiki page). But most of all, team members will be busy working on their features rather than updating the documentation.
It works on my machine problem
This is a magical statement (:-)) that we can hear from those who have set up the environment correctly on their machine. If we have not set up the important configurations like path variables (JAVA_HOME, etc.) then the application will not work on the machine. Thus, each developer should follow the exact steps to reproduce the infrastructure that is required to run the project.
Missing the Estimation
Few teams will be missing the actual estimate (during the Scrum) of the cost of setting up the local machine environment. Ultimately, it will add to the development time.
Learning
Every developer feels proud to learn! But sometimes we miss out on such learning because of a certain setup of the local environment. An example I can think of from my own experience is that making Spark uses the python pyspark library. I keep putting it off because of the initial configuration I have to do.
Solution
We could replicate the (at least partially) customised infrastructure for each project and above all we could save the configurations in the source control. We can bring the entire environment with a few commands!
Yes, we can do this with VSCode’s help with remote containers and dockers.
What kind of sophistication VSCode Remote Development will offer to developers?
The infrastructure setup for Python, Go, Node js, React js, C, C++, Java, or any other language-specific projects are a kind of tedious work. Just think, some of the projects you’re working on have Python 2.x as a base, and some others have Python 3.x as a base. During the development, we used to toggle between projects and we update the language Version Path correctly on our local machine. Some projects need a database as a dependency and some have other tools like jq. That list is going to get longer and longer. All tools should be configured properly to start the application. For example, JAVA_HOME is an important Environment Variable that we used to update depending on the project setup.
Manual Local Machine Setup
We have to do the following to run any application on the local machine,
- Infrastructure Setup: Install language tools (python, java, etc.) or any other utilities (jq, etc.)
- Infrastructure Config: Setup environment variables (JAVA_HOME), python virtual environments, database setup, etc.
- IDE & Extensions Config: To edit and debug the app in a sophisticated way.
We need to make all of the above configurations on each developer machine and it is time-consuming work for some of the projects.
VSCode Remote Container + Docker
As a developer, once the basic infrastructure is configured, then they don’t need to spend time on the environment setup. They can simply open the directory in VSCode from any machine (If Docker & the VSCode remote container installed) and Just start the development.
As shown in the above image, imagine that one of our teammates identifies and adds the Docker and VSCode Remote Container configuration into the .devcontainer folder. The developer saved the dev container config in the source control.
When our team opens the app folder in VSCode and VSCode will rebuild the infrastructure and make it available for development.
As we can see, there is no manual work required as VSCode and VSCode Remote Container will handle this. As a result, developers may tend to focus on their development activities.
Please check out this blog to understand how a SpringBoot developer can leverage the VSCode Remote Container to provide a sophisticated SpringBoot development environment. This demo helps you to understand this concept better.
Step by step guides for different projects
The idea of isolating the environment with strong IDE support deserves to be explored since it saves developer hours and improves productivity. Please watch-out this space to figure out the prerequisites and how to set it up for SpringBoot, python and other projects.
SpringBoot Dev Environment
- VSCode SpringBoot Demo: Demonstrates how a developer can leverage VSCode Remote Container to provide a sophisticated SpringBoot development environment.
- VSCode SpringBoot Configuration: This blog explains about How we can configure Docker with VSCode Remote Container to provide a sophisticated development environment for SpringBoot software development
- VSCode SpringBoot Config Optimisation: This blog explains how to optimise the SpringBoot Development Environment with the help of Docker and VSCode Remote Container.
How is it different from maintaining infra from docker-compose?
Those who have configured their infrastructure on the Docker or Docker-Compose file would think that how this approach is truly different.
This blog is not about comparing such approaches and coming up with the best. This blog will make the technical community aware of another option for setting up their environment with rich IDE support
- There is no need to use the docker-build and docker-run command to make the environments appear. As a user, I just need to open the application in VSCode, Rest the VSCode will look after. But internally, VSCode orchestrates the right commands to get the environment up and running.
- No need to manually mount your source code to the Docker containers because VSCode mounts the source code and makes it available.
- Debugging will be much easier since there is no need to do any extra work to debug the application inside the container.
- Out of box support for the extensions. VSCode encourages providing a list of extensions tailored for each language and framework. Also, imagine that VSCode will offer the set of extensions that suits to run the specific applications.
In my view, this VSCode remote container will evangelise this environmental isolation (through docker) to all developers regardless of the developer’s experience in the docker.
Ragunath Rajasekaran has experience in developing full stack applications using SpringBoot, Node, React and GraphQl technologies. He is also the AWS & Azure cloud specialist who uses the infrastructure as code (IAC) via Terraform. He worked with Spark & Hive Big Data technologies. He debuted his career as an iOS developer.
Let’s connect to Ragunath Rajasekaran through LinkedIn, GitHub, Dev.to, Medium Email Subscription
