rsnext/examples/with-docker-multi-env/README.md

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

65 lines
1.9 KiB
Markdown
Raw Normal View History

[New Example] with docker - multiple deployment environments (#34015) ## Documentation / Examples - [x] Make sure the linting passes by running `yarn lint` --- ## Context Having 3 environments: - Development: for doing testing - Staging: for doing UAT testing - Production: for users In each environment, the Next.js application makes API calls to the corresponding API gateway: - Development: https://api-development.com - Staging: https://api-staging.com - Production: https://api-production.com Using `NEXT_PUBLIC_API_URL` for the `baseUrl` of [axios](https://axios-http.com/docs/intro). Since the `NEXT_PUBLIC_API_URL` is replaced during _build time_, we have to manage to provide the corresponding `.env.production` files for Docker at _build time_ for each environment. ## Solution Since we are using CI services for dockerization, we could setup the CI to inject the correct `.env.production` file into the cloned source code, (this is actually what we did). Doing that would require us to touch the CI settings. Another way is using multiple Dockerfile (the former only need to use one Dockerfile), and the trick is copying the corresponding `env*.sample` and rename it to `.env.production` then putting it into the Docker context. Doing this way, everything is managed in the source code. ``` > Dockerfile # Development environment COPY .env.development.sample .env.production # Staging environment COPY .env.staging.sample .env.production # Production environment COPY .env.production.sample .env.production ``` Testing these images locally is also simple, by issuing the corresponding Makefile commands we can simulate exactly how the image will be built in the CI environment. ## How to use For development environment: ``` make build-development make start-development ``` For staging environment: ``` make build-staging make start-staging ``` For production environment: ``` make build-production make start-production ``` ## Conclusion This example shows one way to solve the three-environment model in software development when building a Next.js application. There might be another better way and I would love to know about them as well. I'm making this example because I can't find any example about this kind of problem. Co-authored-by: Tú Nguyễn <93700515+tunguyen-ct@users.noreply.github.com>
2022-02-05 19:13:01 +01:00
# With Docker - Multiple Deployment Environments
This examples shows how to use Docker with Next.js and deploy to multiple environment with different env values. Based on the [deployment documentation](https://nextjs.org/docs/deployment#docker-image).
## How to use
Execute [`create-next-app`](https://github.com/vercel/next.js/tree/canary/packages/create-next-app) with [npm](https://docs.npmjs.com/cli/init), [Yarn](https://yarnpkg.com/lang/en/docs/cli/create/), or [pnpm](https://pnpm.io) to bootstrap the example:
[New Example] with docker - multiple deployment environments (#34015) ## Documentation / Examples - [x] Make sure the linting passes by running `yarn lint` --- ## Context Having 3 environments: - Development: for doing testing - Staging: for doing UAT testing - Production: for users In each environment, the Next.js application makes API calls to the corresponding API gateway: - Development: https://api-development.com - Staging: https://api-staging.com - Production: https://api-production.com Using `NEXT_PUBLIC_API_URL` for the `baseUrl` of [axios](https://axios-http.com/docs/intro). Since the `NEXT_PUBLIC_API_URL` is replaced during _build time_, we have to manage to provide the corresponding `.env.production` files for Docker at _build time_ for each environment. ## Solution Since we are using CI services for dockerization, we could setup the CI to inject the correct `.env.production` file into the cloned source code, (this is actually what we did). Doing that would require us to touch the CI settings. Another way is using multiple Dockerfile (the former only need to use one Dockerfile), and the trick is copying the corresponding `env*.sample` and rename it to `.env.production` then putting it into the Docker context. Doing this way, everything is managed in the source code. ``` > Dockerfile # Development environment COPY .env.development.sample .env.production # Staging environment COPY .env.staging.sample .env.production # Production environment COPY .env.production.sample .env.production ``` Testing these images locally is also simple, by issuing the corresponding Makefile commands we can simulate exactly how the image will be built in the CI environment. ## How to use For development environment: ``` make build-development make start-development ``` For staging environment: ``` make build-staging make start-staging ``` For production environment: ``` make build-production make start-production ``` ## Conclusion This example shows one way to solve the three-environment model in software development when building a Next.js application. There might be another better way and I would love to know about them as well. I'm making this example because I can't find any example about this kind of problem. Co-authored-by: Tú Nguyễn <93700515+tunguyen-ct@users.noreply.github.com>
2022-02-05 19:13:01 +01:00
```bash
npx create-next-app --example with-docker-multi-env nextjs-docker-multi-env
# or
yarn create next-app --example with-docker-multi-env nextjs-docker-multi-env
# or
pnpm create next-app --example with-docker-multi-env nextjs-docker-multi-env
[New Example] with docker - multiple deployment environments (#34015) ## Documentation / Examples - [x] Make sure the linting passes by running `yarn lint` --- ## Context Having 3 environments: - Development: for doing testing - Staging: for doing UAT testing - Production: for users In each environment, the Next.js application makes API calls to the corresponding API gateway: - Development: https://api-development.com - Staging: https://api-staging.com - Production: https://api-production.com Using `NEXT_PUBLIC_API_URL` for the `baseUrl` of [axios](https://axios-http.com/docs/intro). Since the `NEXT_PUBLIC_API_URL` is replaced during _build time_, we have to manage to provide the corresponding `.env.production` files for Docker at _build time_ for each environment. ## Solution Since we are using CI services for dockerization, we could setup the CI to inject the correct `.env.production` file into the cloned source code, (this is actually what we did). Doing that would require us to touch the CI settings. Another way is using multiple Dockerfile (the former only need to use one Dockerfile), and the trick is copying the corresponding `env*.sample` and rename it to `.env.production` then putting it into the Docker context. Doing this way, everything is managed in the source code. ``` > Dockerfile # Development environment COPY .env.development.sample .env.production # Staging environment COPY .env.staging.sample .env.production # Production environment COPY .env.production.sample .env.production ``` Testing these images locally is also simple, by issuing the corresponding Makefile commands we can simulate exactly how the image will be built in the CI environment. ## How to use For development environment: ``` make build-development make start-development ``` For staging environment: ``` make build-staging make start-staging ``` For production environment: ``` make build-production make start-production ``` ## Conclusion This example shows one way to solve the three-environment model in software development when building a Next.js application. There might be another better way and I would love to know about them as well. I'm making this example because I can't find any example about this kind of problem. Co-authored-by: Tú Nguyễn <93700515+tunguyen-ct@users.noreply.github.com>
2022-02-05 19:13:01 +01:00
```
Enter the values in the `.env.development.sample`, `.env.staging.sample`, `.env.production.sample` files to be used for each environments.
## Using Docker and Makefile
### Development environment - for doing testing
```
make build-development
make start-development
```
Open http://localhost:3001
### Staging environment - for doing UAT testing
```
make build-staging
make start-staging
```
Open http://localhost:3002
### Production environment - for users
```
make build-production
make start-production
```
Open http://localhost:3003
## Running Locally
First, run the development server:
```bash
npm run dev
# or
yarn dev
```
Open [http://localhost:3000](http://localhost:3000) with your browser to see the result.
You can start editing the page by modifying `pages/index.js`. The page auto-updates as you edit the file.
[API routes](https://nextjs.org/docs/api-routes/introduction) can be accessed on [http://localhost:3000/api/hello](http://localhost:3000/api/hello). This endpoint can be edited in `pages/api/hello.js`.
The `pages/api` directory is mapped to `/api/*`. Files in this directory are treated as [API routes](https://nextjs.org/docs/api-routes/introduction) instead of React pages.