An open API service indexing awesome lists of open source software.

https://github.com/platformatic/demo-watt-docker-build


https://github.com/platformatic/demo-watt-docker-build

Last synced: about 1 month ago
JSON representation

Awesome Lists containing this project

README

          

# Demo

## Docker Build

This project includes a Dockerfile for containerization. The build process requires npm authentication for accessing private packages.

### Prerequisites

The Docker build requires an npm authentication token to access the private `@platformatic/wattpro` package. You can get this token from your npm account settings.

### Building the Docker Image

To build the Docker image, you must provide your npm auth token as a BuildKit secret, for instance setting the `NPM_TOKEN` env variable.

```bash
docker build --secret id=npm_token,env=NPM_TOKEN -t demo .
```

**Important:** The build will fail without the npm_token secret, as the Dockerfile needs to access private npm packages during the build process.

### Running the Container

Once built, you can run the container with:

```bash
# Run with node
docker run -p 3042:3042 --name demo -e PLATFORM_TYPE=node demo

# Run with watt platform
docker run -p 3042:3042 --name demo -e PLATFORM_TYPE=watt demo

# Run with wattpro platform
docker run -p 3042:3042 --name demo -e PLATFORM_TYPE=wattpro demo
```

The application will be available at `http://localhost:3042`.

### Container Management

```bash
# Stop a running container
docker stop demo

# Remove the container
docker rm demo

# Stop and remove in one command
docker rm -f demo
```

#### Environment Variables

The following environment variables are pre-configured in the Docker image:

- `PLT_SERVER_HOSTNAME=0.0.0.0` - Binds to all interfaces for Docker
- `PORT=3042` - Default port
- `PLT_SERVER_LOGGER_LEVEL=info` - Logging level

### Security Note

The Dockerfile uses BuildKit secrets for maximum security:

- The npm token is never stored in image layers or history
- Secrets are only available during build time and are automatically cleaned up
- The image does not contain any sensitive data
- This is the most secure approach for handling build-time secrets

**Why we don't need multi-stage builds with secrets:**
Since BuildKit secrets are never stored in image layers or history, there's no security benefit to using multi-stage builds. The secrets are automatically cleaned up after each RUN command, making the final image equally secure whether using single or multi-stage builds.