Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

add devcontainer setup docs #154

Open
wants to merge 6 commits into
base: main
Choose a base branch
from
Open
Show file tree
Hide file tree
Changes from 2 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion docs/getting-started/server/database/_category_.yml
Original file line number Diff line number Diff line change
@@ -1,2 +1,2 @@
label: "Databases"
position: 2
position: 3
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ As I read through all this I started to feel like the guide in this PR is a sub-page of the server's getting started page since there's repeated content. I think this needs some organizing and you wouldn't need this move.

Copy link
Member

@Hinton Hinton Jul 13, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree, maintaining the cloud and self-hosted configs are already confusing enough without adding a third document. It would be nice to have a single guide that gives you two options towards the end.

Copy link
Contributor Author

@tangowithfoxtrot tangowithfoxtrot Jul 13, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd love to integrate the container setup into the standard setup guide, but I am not sure how to do so, as even the sections that are shared between the two setups have a few steps that vary slightly.

Is there some way to indicate variance of the setup process at the step level without adding new "Dev Container - Bitwarden Dev" "Dev Container - Community Dev" options in the dropdown menu?

Copy link
Member

@Hinton Hinton Jul 14, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe tabs? Docusaurus mdx lets you write & use react components if you want. And we could even look into switching the getting started page into a react page if needed.

267 changes: 267 additions & 0 deletions docs/getting-started/server/guide-vscode.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,267 @@
---
sidebar_position: 2
---

# VS Code Dev Containers

This page will show you how to set up a local Bitwarden server for development purposes utilizing
Visual Studio Code Dev Containers. You can read more about this in the
[Visual Studio Code Dev Containers documentation](https://code.visualstudio.com/docs/devcontainers/containers).

The Bitwarden server is comprised of several services that can run independently. For a basic
development setup, you will need the **Admin**, **Api**, and **Identity** services.

:::info

Before you start: make sure you’ve installed the recommended
[Tools and Libraries](../tools/index.md). Namely, the following:

- Docker Desktop
- [Visual Studio Code](https://code.visualstudio.com/)
- Azure Data Studio

:::

## Clone the repository

1. Clone the Bitwarden Server project:

```bash
git clone https://github.com/bitwarden/server.git
```

2. Open a terminal and navigate to the root of the cloned repository.

:::caution

When first opening the repository in Visual Studio Code, you will be prompted to reopen the folder
in a Dev Container. If you have not completed the steps in the
[Configure Env File](#configure-env-file) section below, the creation of the Dev Container will
fail.

:::

## Configure Git

1. Configure Git to ignore the Prettier revision:

```bash
git config blame.ignoreRevsFile .git-blame-ignore-revs
```

2. _(Optional)_ Set up the pre-commit `dotnet format` hook:

```bash
git config --local core.hooksPath .git-hooks
```

Formatting requires a full build, which may be too slow to do every commit. As an alternative,
you can run `dotnet format` from the command line when convenient (e.g. before requesting a PR
review).

## Configure Env File
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💭 Can we start this documentation right here? The prior two steps are a repeat of the main setup guide.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⛏️ Would be nice to use .env instead of "Env".


The Dev Container will automatically load the environment variables from the values in `dev/.env`.
To get started, copy the example file:

1. ```bash
cd dev
cp .env.example .env
```

2. Open `.env` with your preferred editor.

3. Set the `MSSQL_SA_PASSWORD` variable. This will be the password for your MSSQL database server.

:::caution

Your MSSQL password must comply with the following
[password complexity guidelines](https://docs.microsoft.com/en-us/sql/relational-databases/security/password-policy?view=sql-server-ver15#password-complexity)

- It must be at least eight characters long.
- It must contain characters from three of the following four categories:
- Latin uppercase letters (A through Z)
- Latin lowercase letters (a through z)
- Base 10 digits (0 through 9)
- Non-alphanumeric characters such as: exclamation point (!), dollar sign ($), number sign (#), or
percent (%).

:::
Comment on lines +76 to +89
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

❓ Can we include this somewhere more general, or on the setup guide itself?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It actually exists in the standard setup guide as well. I could remove this call-out entirely from the dev container, but I think I'd still run into the issue described here.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On second thought, perhaps that call-out from both guides could be moved here?


4. You can change the other variables or use their default values. Save and quit this file.

### SQL Server
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💭 As I read down here I am seeing more repeated content. How can we better push this all upward and just focus on the Dev Containers content? Keeps it DRY.

Copy link
Contributor Author

@tangowithfoxtrot tangowithfoxtrot Jul 13, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I started this guide as a copy of the server setup guide and took the approach of removing mention of setup steps that the containers handle for us now. There's definitely still some repeating content that I left in, as there are a few things that couldn't be fully automated without a ton of workarounds (mostly for Windows hosts) that still require some user interaction.

I could try to link back to the standard server setup guide for some of the repeating sections, but many of them have just one or two steps that vary just based on the fact that the parts of the setup that require manual interaction (env and secrets) is largely the same, but the way you have to interact with things like that and starting the DB, Azurite, and other containers varies slightly.

As an example, the step that follows step #\4 from the above section in the standard setup guide instructs the user to run docker compose up ... to start the container stack, but doing so using the dev container approach would be redundant, and possibly confusing. I'm unsure of how I might utilize existing parts of the standard setup guide for things like this.

I'd definitely appreciate your thoughts though. I'd love to simplify the docs for this as much as possible and reuse what we can.

Copy link
Contributor Author

@tangowithfoxtrot tangowithfoxtrot Jul 13, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The first thought that comes to mind if we wanted to have slight variance in the steps that do still manually require some user interaction would be to add a "Dev Container" option to the top-right dropdown menu, or something like that.

Doing so might also be weird though because that menu currently distinguishes between internal engineering and external community dev configuration guides. The dev containers also have their own community/internal configurations, so we'd have to further subdivide that in a way that makes sense.


In order to support ARM based development environments such as the M1 Macs, we use the
[Azure SQL Edge](https://hub.docker.com/_/microsoft-azure-sql-edge) docker container instead of a
normal [Microsoft SQL Server](https://hub.docker.com/_/microsoft-mssql-server) container. It behaves
mostly identical to a regular SQL Server instance and runs on port 1433.

You can connect to it using Azure Data Studio using the following credentials:

- Server: localhost
- Username: sa
- Password: (the password you set in `dev/.env`)

### Mailcatcher

The server uses emails for many user interactions. We provide a pre-configured instance of
[MailCatcher](https://mailcatcher.me/), which catches any outbound email and prevents it from being
sent to real email addresses. You can open its web interface at
[http://localhost:1080](http://localhost:1080).

## Configure User Secrets

[User secrets](https://docs.microsoft.com/en-us/aspnet/core/security/app-secrets?view=aspnetcore-6.0)
are a method for managing application settings on a per-developer basis. They override the settings
in `appSettings.json` of each project. Your user secrets file should match the structure of the
`appSettings.json` file for the settings you intend to override.

We provide a helper script which simplifies setting user secrets for all projects in the server
repository.

1. Get a template `secrets.json`. We need to get an initial version of `secrets.json`, which you
will modify for your own secrets values.

<bitwarden>

- Copy the user secrets file from the shared Development collection into the `dev` folder.
- If you don't have access to the Development collection, contact our IT Manager to arrange
access. Make sure you have first set up a Bitwarden account using your company email address.
- This `secrets.json` is configured to use the dockerized Azurite and MailCatcher instances and
is recommended for this guide.

</bitwarden>

2. Update `secrets.json` with your own values:

- `sqlServer` > `connectionString`: insert your password where indicated
- `identityServer` > `certificateThumbprint`: insert your Identity certificate thumbprint from
the previous step
- `dataProtection` > `certificateThumbprint`: insert your Data Protection certificate thumbprint
from the previous step

<community>

- `installation` > `id` and `key`:
[request a hosting installation Id and Key](https://bitwarden.com/host/) and insert them here
- `licenseDirectory`: set this to an empty directory, this is where uploaded license files will
be stored.

</community>

3. Once you have your `secrets.json` complete, proceed to
[Starting the Dev Container Environment](#starting-the-dev-container-environment).

## Starting the Dev Container Environment

You are now ready to build and run your development server.

1. Start the Dev Container by opening the Command Palette (Ctrl/Command+Shift+P) and selecting
**Dev Containers: Reopen in Container**:

![Reopen in Container](reopen-in-container.png)

2. Select the appropriate dev container configuration:

![Select container configuration](select-container-configuration.png)

3. Wait for the container to build and start. The first time you open the container, it will take a
few minutes to build.

4. Once the container has finished building for the first time, you will be greeted with the
`postCreateCommand` script, which will walk you through generating and applying any additional
secrets or certificates required for the server to run.

5. Follow the on-screen prompts to finish setting up the server. Then, proceed to
[Build and Run the Server](#build-and-run-the-server).

## Build and Run the Server

You are now ready to build and run your development server.

1. Open a new terminal window in the root of the repository.
2. Restore the nuget packages required for the Identity service:

```bash
cd src/Identity
dotnet restore
```

3. Start the Identity service:

```bash
dotnet run
```

4. Test that the Identity service is alive by navigating to
[http://localhost:33656/.well-known/openid-configuration](http://localhost:33656/.well-known/openid-configuration)
5. In another terminal window, restore the nuget packages required for the Api service:

```bash
cd src/Api
dotnet restore
```

6. Start the Api Service:

```bash
dotnet run
```

7. Test that the Api service is alive by navigating to
[http://localhost:4000/alive](http://localhost:4000/alive)
8. Connect a client to your local server by configuring the client’s Api and Identity endpoints.
Refer to
[https://bitwarden.com/help/article/change-client-environment/](https://bitwarden.com/help/article/change-client-environment/)
and the instructions for each client in the Contributing Documentation.

:::info

If you cannot connect to the Api or Identity projects, check the terminal output to confirm the
ports they are running on.

:::

:::note

We recommend continuing with the [Web Vault](../clients/web-vault/index.mdx) afterwards, since many
administrative operations can only be performed in it.

:::

## Debugging

You can use the debugger in Visual Studio Code to debug the server by following these steps:

1. Click the "Debug and Run" button in the left sidebar of Visual Studio Code.

2. Select the desired debug configuration from the dropdown menu.

3. Click the "Start Debugging" button to start the debugger.

## Managing and updating the Dev Containers

After you’ve run the deployed the Dev Containers, you can use the
[Docker Dashboard](https://docs.docker.com/desktop/dashboard/) or `docker` CLI to manage your
containers. You should see your containers running under the `bitwarden_common` group.

:::caution

Changing `MSSQL_SA_PASSWORD` variable after first running the Dev Containers will require a
re-creation of the storage volume.

**Warning: this will delete your development database.**
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There's a warn decorator you can use here, but not sure if it works within a surrounding block.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I updated the language and formatting for this process to hopefully make it more clear.


To do this, exit the Dev Containers and run the following commands from the
`./.devcontainer/bitwarden_common` directory:

```bash
docker compose down
docker volume rm bitwarden_common-bitwarden_mssql-1
```

After that, you can re-open the Dev Containers in Visual Studio Code and the database will be
recreated with the new password.

:::
7 changes: 7 additions & 0 deletions docs/getting-started/server/guide.md
Original file line number Diff line number Diff line change
Expand Up @@ -22,6 +22,13 @@ Before you start: make sure you’ve installed the recommended

:::

:::info

A guide for developing in VS Code Dev containers can be found [here](./guide-vscode) if you prefer
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⛏️ Capital "C" for "Containers".

This is more of my style I suppose, but I try to future-proof this a bit with something like a list format. This could instead be reworded as a collection of guides available, and then you might want to have this in a subfolder of "guides". We have VS Code and VS material here and perhaps they should follow your pattern here so it isn't unique and on its own.

I realize that's easy to ask, but it'd be a nice structure change.

developing in a containerized environment.

:::

## Clone the repository

1. Clone the Bitwarden Server project:
Expand Down
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.