{ "componentChunkName": "component---src-templates-blog-post-tsx", "path": "/blog/2022-01-24-backstage-with-vscode/", "result": {"data":{"blogPost":{"title":"Tutorial: Easier onboarding with Backstage and VSCode dev containers","slug":"/blog/2022-01-24-backstage-with-vscode/","authorNodes":[{"name":"Min Kim","slug":"/people/min-kim/"}],"markdown":{"html":"

An often underrated aspect of developer onboarding is how quickly a new contributor can go from cloning the source code to running the project on their machine. An onboarding experience full of friction can be discouraging and leave a poor impression, while a smooth one is valuable for new and seasoned contributors alike.

\n

However, onboarding can be especially challenging for Backstage because it is a full-stack application. Developing a Backstage-based Developer Portal requires having a recent version of Node.js, Yarn, and PostgreSQL running on the developer's machine. These are relatively easy to install on macOS and Linux but can be challenging on Windows, especially for someone new to the Node.js ecosystem.

\n

At Frontside, we've had success improving onboarding by using dev containers, which spins up a docker-based local environment with all the dependencies that a project needs.

\n

Dev containers has a CLI called devcontainer-cli you can use to open the container from the command line. It will open in VSCode, which uses Remote Containers Extension to create a smooth integration.

\n

For the most part, running dev containers inside VSCode feels like the application is running on your machine. Once you've added dev containers to your project, there’s a clear pathway to adopting GitHub Codespaces, which makes onboarding even easier.

\n

This blog post will explain setting up dev containers for Backstage projects as a first step to create a streamlined onboarding for developers.

\n

Requirements

\n

Before you get started, make sure you have the following:

\n\n

Create a Backstage App

\n

To spin up a dev container, you first need a project to work from. You can instantiate a Backstage app using @backstage/create-app:

\n
npx @backstage/create-app
\n

For this tutorial, you'll be using PostgreSQL:

\n

backstage-create-app

\n

Once the app is done installing, open the new app's workspace in visual studio code and set up a dev container.

\n

Opening a Project inside a dev container

\n

If you have the Remote Containers extension installed, you should be able to access its commands. Press F1 and select Remote-Containers: Open Folder in Container...:

\n

open-folder-container

\n

VSCode will detect that you do not have dev container configurations yet and prompt you to select a predefined container. You can go ahead and select any of them, as you'll be replacing all of those configurations later.

\n

Once you make your selection, VSCode will create configuration files in the .devcontainer directory, build the container according to those files, and launch your workspace in the container. (You can go to your Docker Desktop dashboard to confirm that the new container is running.)

\n

If you change your dev container configuration, you can run Remote-Containers: Rebuild Container. And when you are ready to exit out of your dev container, run Remote-Containers: Reopen Folder Locally.

\n

Now that you know how to launch and exit out of dev containers, you need to add configurations to run Backstage.

\n

Docker Compose - Postgres

\n

If you try to start up Backstage now, you'll get an error in the terminal about there being no database to connect to. This is because you're not running an instance of Postgres yet, so you should start there. At the root of your project workspace create a docker-compose.yaml file:

\n
version: \"3.8\"\n\nservices:\n  my_postgres_db:\n    image: postgres\n    environment:\n      POSTGRES_USER: postgres_username\n      POSTGRES_PASSWORD: postgres_password
\n

You're creating a my_postgres_db service with the official postgres docker image and providing it a username and password to bootstrap a Postgres account for local development.

\n

Docker Compose - dev container 

\n

Next, create a service for your dev container (this will replace the one that VSCode automatically generated earlier).

\n
services:\n  my_postgres_db:\n    ...\n  my_devcontainer:\n    image: mcr.microsoft.com/vscode/devcontainers/typescript-node:14\n    command: /bin/sh -c \"while sleep 1000; do:; done\"\n    volumes:\n      - .:/workspace\n    environment:\n      POSTGRES_HOST: my_postgres_db\n      POSTGRES_USER: postgres_username\n      POSTGRES_PASSWORD: postgres_password
\n

For your dev container image, you’re using one of the docker images created by Microsoft and running a shell command to prevent the container from exiting on its own as suggested in the devcontainer docs.

\n

For a container to have all of the files of the backstage app, you need to add volumes: .:/workspace as shown in the previous snippet. This will take the current directory (relative to the docker-compose file) and copy its contents to your container's /workspace directory.

\n

You're also passing in environment variables to access the local instance of Postgres. These should correspond to the values you specified when creating the my_postgres_db service. (Alternatively, you could provide these values as environment variables and pass them through the start script of your backstage backend.)

\n

Rebuild devcontainer

\n

Now you need to update your dev container configurations to use the docker-compose file you created:

\n
// .devcontainers/devcontainer.json\n{\n  \"dockerComposeFile\": \"../docker-compose.yaml\",\n  \"service\": \"my_devcontainer\",\n  \"workspaceFolder\": \"/workspace\"\n}
\n

For these changes to be applied, you will need to rebuild your dev container by running either Remote-Containers: Rebuild Container or Rebuild and Reopen in Container, depending on if you returned to your local environment or if you're still in the first dev container you launched. You can go ahead and delete the other files that were created inside .devcontainer/.

\n

Using Persistent Volumes

\n

At this point, if you try to add a dependency or run yarn install, you may notice that it takes much longer than it usually does in your local environment. This is because when you create files in a docker container, it writes to the container's writable layer, which is not very fast. The standard practice (as suggested by docker docs) is to use volumes.

\n

In your docker-compose file, add the three node_modules directories of your backstage app:

\n
services:\n  my_postgres_db:\n    ...\n  my_devcontainer:\n    ...\n    volumes:\n      - .:/workspace\n      - /workspace/node_modules\n      - /workspace/packages/app/node_modules\n      - /workspace/packages/backend/node_modules
\n

This syntax can be a little confusing at first, and you may be wondering if and why .:/workspace omits node_modules. Although they are nested under the same volumes property, what they achieve is different. When you specify both a source and target path, docker-compose will treat that as a bind mount. But when you pass in only a target path, docker-compose will create an anonymous volume.

\n

What's happening here is docker-compose first copies your backstage app to the /workspace directory of your dev container and then maps out the contents of node_modules to persistent volumes. You can read more about the differences between a bind mount and a volume here.

\n

Once you complete these steps and rebuild and reopen your dev container, you should see a significant improvement when you run yarn install.

\n

Dev containers are a first step

\n

Now that you know how to set up dev containers optimized for Backstage development, you can make it easier for your teammates to contribute to your Developer Portal (regardless of whether they use macOS, Linux or Windows) by including the settings explained in this tutorial in your repository.

\n

The setup we explained in this tutorial also allows people to opt-in (or not) to running dev containers, so these changes do not affect anybody with other local development preferences.

\n

Dev containers are meant to lower barriers for those who cannot run the project locally. However, it's important to point out that even though dev containers are a convenient way to run the project, the DX of developing in a dev container is still inferior in some ways to running the project locally because it introduces the overhead of running Docker containers. With that said, we still believe that they are a handy tool and will drive the DX of your project in the right direction.

","frontmatter":{"date":"January 24, 2022","description":"In this tutorial, you'll learn how to set up dev containers to make it easier to onboard developers.","tags":["backstage"],"img":{"childImageSharp":{"fixed":{"src":"/static/69c0454f06a75c884b68d6358a0058af/31987/2022-backstage-dev-containers-windows.png"}}}}}}},"pageContext":{"id":"c826c44c-ed6e-55cb-8f00-5b39ccd110bd"}}, "staticQueryHashes": ["1241260443"]}