From 326fe555ba7379210a4d57628873a444aee72361 Mon Sep 17 00:00:00 2001 From: Craig Osterhout Date: Tue, 16 Jun 2026 12:06:59 -0700 Subject: [PATCH 1/2] guides: clean up non-unique content Signed-off-by: Craig Osterhout --- content/guides/angular/_index.md | 5 +- .../angular/configure-github-actions.md | 323 ----------------- content/guides/angular/deploy.md | 201 ----------- content/guides/angular/run-tests.md | 3 - content/guides/bun/_index.md | 2 - content/guides/bun/configure-ci-cd.md | 132 ------- content/guides/bun/deploy.md | 141 -------- content/guides/bun/develop.md | 3 - content/guides/cpp/_index.md | 3 - content/guides/cpp/configure-ci-cd.md | 133 ------- content/guides/cpp/deploy.md | 143 -------- content/guides/cpp/develop.md | 3 - content/guides/cpp/security.md | 84 ----- content/guides/deno/_index.md | 2 - content/guides/deno/configure-ci-cd.md | 131 ------- content/guides/deno/deploy.md | 141 -------- content/guides/deno/develop.md | 3 - content/guides/dotnet/_index.md | 2 - content/guides/dotnet/configure-ci-cd.md | 148 -------- content/guides/dotnet/deploy.md | 224 ------------ content/guides/dotnet/run-tests.md | 3 - content/guides/golang/_index.md | 2 - content/guides/golang/configure-ci-cd.md | 133 ------- content/guides/golang/deploy.md | 249 ------------- content/guides/golang/run-tests.md | 4 - content/guides/java/_index.md | 2 - content/guides/java/configure-ci-cd.md | 143 -------- content/guides/java/deploy.md | 155 -------- content/guides/java/run-tests.md | 4 - content/guides/nextjs/_index.md | 11 +- .../guides/nextjs/configure-github-actions.md | 332 ----------------- content/guides/nextjs/deploy.md | 199 ---------- content/guides/nextjs/run-tests.md | 3 - content/guides/nodejs/_index.md | 5 +- .../guides/nodejs/configure-github-actions.md | 135 ------- content/guides/nodejs/deploy.md | 274 -------------- content/guides/nodejs/run-tests.md | 3 - content/guides/nodejs/secure-supply-chain.md | 141 -------- content/guides/php/_index.md | 2 - content/guides/php/configure-ci-cd.md | 148 -------- content/guides/php/deploy.md | 146 -------- content/guides/php/run-tests.md | 3 - content/guides/python/_index.md | 2 - .../guides/python/configure-github-actions.md | 161 --------- content/guides/python/deploy.md | 341 ------------------ content/guides/python/lint-format-typing.md | 4 +- content/guides/python/secure-supply-chain.md | 144 -------- content/guides/r/_index.md | 2 - content/guides/r/configure-ci-cd.md | 133 ------- content/guides/r/deploy.md | 147 -------- content/guides/r/develop.md | 3 - content/guides/reactjs/_index.md | 2 - .../reactjs/configure-github-actions.md | 321 ----------------- content/guides/reactjs/deploy.md | 194 ---------- content/guides/reactjs/run-tests.md | 3 - content/guides/ruby/_index.md | 2 - .../guides/ruby/configure-github-actions.md | 111 ------ content/guides/ruby/containerize.md | 3 - content/guides/ruby/deploy.md | 167 --------- content/guides/ruby/develop.md | 3 - content/guides/rust/_index.md | 2 - content/guides/rust/configure-ci-cd.md | 132 ------- content/guides/rust/deploy.md | 238 ------------ content/guides/rust/develop.md | 3 - content/guides/vuejs/_index.md | 5 +- .../guides/vuejs/configure-github-actions.md | 320 ---------------- content/guides/vuejs/deploy.md | 201 ----------- content/guides/vuejs/run-tests.md | 3 - 68 files changed, 8 insertions(+), 6563 deletions(-) delete mode 100644 content/guides/angular/configure-github-actions.md delete mode 100644 content/guides/angular/deploy.md delete mode 100644 content/guides/bun/configure-ci-cd.md delete mode 100644 content/guides/bun/deploy.md delete mode 100644 content/guides/cpp/configure-ci-cd.md delete mode 100644 content/guides/cpp/deploy.md delete mode 100644 content/guides/cpp/security.md delete mode 100644 content/guides/deno/configure-ci-cd.md delete mode 100644 content/guides/deno/deploy.md delete mode 100644 content/guides/dotnet/configure-ci-cd.md delete mode 100644 content/guides/dotnet/deploy.md delete mode 100644 content/guides/golang/configure-ci-cd.md delete mode 100644 content/guides/golang/deploy.md delete mode 100644 content/guides/java/configure-ci-cd.md delete mode 100644 content/guides/java/deploy.md delete mode 100644 content/guides/nextjs/configure-github-actions.md delete mode 100644 content/guides/nextjs/deploy.md delete mode 100644 content/guides/nodejs/configure-github-actions.md delete mode 100644 content/guides/nodejs/deploy.md delete mode 100644 content/guides/nodejs/secure-supply-chain.md delete mode 100644 content/guides/php/configure-ci-cd.md delete mode 100644 content/guides/php/deploy.md delete mode 100644 content/guides/python/configure-github-actions.md delete mode 100644 content/guides/python/deploy.md delete mode 100644 content/guides/python/secure-supply-chain.md delete mode 100644 content/guides/r/configure-ci-cd.md delete mode 100644 content/guides/r/deploy.md delete mode 100644 content/guides/reactjs/configure-github-actions.md delete mode 100644 content/guides/reactjs/deploy.md delete mode 100644 content/guides/ruby/configure-github-actions.md delete mode 100644 content/guides/ruby/deploy.md delete mode 100644 content/guides/rust/configure-ci-cd.md delete mode 100644 content/guides/rust/deploy.md delete mode 100644 content/guides/vuejs/configure-github-actions.md delete mode 100644 content/guides/vuejs/deploy.md diff --git a/content/guides/angular/_index.md b/content/guides/angular/_index.md index 6f28a0f99cf9..3cfe4e32b646 100644 --- a/content/guides/angular/_index.md +++ b/content/guides/angular/_index.md @@ -31,10 +31,7 @@ In this guide, you will learn how to: - Containerize and run an Angular application using Docker. - Set up a local development environment for Angular inside a container. - Run tests for your Angular application within a Docker container. -- Configure a CI/CD pipeline using GitHub Actions for your containerized app. -- Deploy the containerized Angular application to a local Kubernetes cluster for testing and debugging. - -You'll start by containerizing an existing Angular application and work your way up to production-level deployments. +You'll start by containerizing an existing Angular application. --- diff --git a/content/guides/angular/configure-github-actions.md b/content/guides/angular/configure-github-actions.md deleted file mode 100644 index 335ea0f304d5..000000000000 --- a/content/guides/angular/configure-github-actions.md +++ /dev/null @@ -1,323 +0,0 @@ ---- -title: Automate your builds with GitHub Actions -linkTitle: GitHub Actions CI -weight: 60 -keywords: CI/CD, GitHub( Actions), Angular -description: Learn how to configure CI/CD using GitHub Actions for your Angular application. - ---- - -## Prerequisites - -Complete all the previous sections of this guide, starting with [Containerize an Angular application](containerize.md). - -You must also have: -- A [GitHub](https://github.com/signup) account. -- A verified [Docker Hub](https://hub.docker.com/signup) account. - ---- - -## Overview - -In this section, you'll set up a CI/CD pipeline using [GitHub Actions](https://docs.github.com/en/actions) to automatically: - -- Build your Angular application inside a Docker container. -- Run tests in a consistent environment. -- Push the production-ready image to [Docker Hub](https://hub.docker.com). - ---- - -## Connect your GitHub repository to Docker Hub - -To enable GitHub Actions to build and push Docker images, you’ll securely store your Docker Hub credentials in your new GitHub repository. - -### Step 1: Generate Docker Hub credentials and set GitHub secrets - -1. Create a Personal Access Token (PAT) from [Docker Hub](https://hub.docker.com) - 1. Go to your **Docker Hub account → Account Settings → Security**. - 2. Generate a new Access Token with **Read/Write** permissions. - 3. Name it something like `docker-angular-sample`. - 4. Copy and save the token — you’ll need it in Step 4. - -2. Create a repository in [Docker Hub](https://hub.docker.com/repositories/) - 1. Go to your **Docker Hub account → Create a repository**. - 2. For the Repository Name, use something descriptive — for example: `angular-sample`. - 3. Once created, copy and save the repository name — you’ll need it in Step 4. - -3. Create a new [GitHub repository](https://github.com/new) for your Angular project - -4. Add Docker Hub credentials as GitHub repository secrets - - In your newly created GitHub repository: - - 1. Navigate to: - **Settings → Secrets and variables → Actions → New repository secret**. - - 2. Add the following secrets: - - | Name | Value | - |-------------------|--------------------------------| - | `DOCKER_USERNAME` | Your Docker Hub username | - | `DOCKERHUB_TOKEN` | Your Docker Hub access token (created in Step 1) | - | `DOCKERHUB_PROJECT_NAME` | Your Docker Project Name (created in Step 2) | - - These secrets allow GitHub Actions to authenticate securely with Docker Hub during automated workflows. - -5. Connect Your Local Project to GitHub - - Link your local project `docker-angular-sample` to the GitHub repository you just created by running the following command from your project root: - - ```console - $ git remote set-url origin https://github.com/{your-username}/{your-repository-name}.git - ``` - - >[!IMPORTANT] - >Replace `{your-username}` and `{your-repository}` with your actual GitHub username and repository name. - - To confirm that your local project is correctly connected to the remote GitHub repository, run: - - ```console - $ git remote -v - ``` - - You should see output similar to: - - ```console - origin https://github.com/{your-username}/{your-repository-name}.git (fetch) - origin https://github.com/{your-username}/{your-repository-name}.git (push) - ``` - - This confirms that your local repository is properly linked and ready to push your source code to GitHub. - -6. Push your source code to GitHub - - Follow these steps to commit and push your local project to your GitHub repository: - - 1. Stage all files for commit. - - ```console - $ git add -A - ``` - This command stages all changes — including new, modified, and deleted files — preparing them for commit. - - - 2. Commit the staged changes with a descriptive message. - - ```console - $ git commit -m "Initial commit" - ``` - This command creates a commit that snapshots the staged changes with a descriptive message. - - 3. Push the code to the `main` branch. - - ```console - $ git push -u origin main - ``` - This command pushes your local commits to the `main` branch of the remote GitHub repository and sets the upstream branch. - -Once completed, your code will be available on GitHub, and any GitHub Actions workflow you’ve configured will run automatically. - -> [!NOTE] -> Learn more about the Git commands used in this step: -> - [Git add](https://git-scm.com/docs/git-add) – Stage changes (new, modified, deleted) for commit -> - [Git commit](https://git-scm.com/docs/git-commit) – Save a snapshot of your staged changes -> - [Git push](https://git-scm.com/docs/git-push) – Upload local commits to your GitHub repository -> - [Git remote](https://git-scm.com/docs/git-remote) – View and manage remote repository URLs - ---- - -### Step 2: Set up the workflow - -Now you'll create a GitHub Actions workflow that builds your Docker image, runs tests, and pushes the image to Docker Hub. - -1. Go to your repository on GitHub and select the **Actions** tab in the top menu. - -2. Select **Set up a workflow yourself** when prompted. - - This opens an inline editor to create a new workflow file. By default, it will be saved to: - `.github/workflows/main.yml` - - -3. Add the following workflow configuration to the new file: - -```yaml -name: CI/CD – Angular Application with Docker - -on: - push: - branches: [main] - pull_request: - branches: [main] - types: [opened, synchronize, reopened] - -jobs: - build-test-push: - name: Build, Test, and Push Docker Image - runs-on: ubuntu-latest - - steps: - # 1. Checkout source code - - name: Checkout source code - uses: actions/checkout@{{% param "checkout_action_version" %}} - with: - fetch-depth: 0 - - # 2. Set up Docker Buildx - - name: Set up Docker Buildx - uses: docker/setup-buildx-action@{{% param "setup_buildx_action_version" %}} - - # 3. Cache Docker layers - - name: Cache Docker layers - uses: actions/cache@{{% param "cache_action_version" %}} - with: - path: /tmp/.buildx-cache - key: ${{ runner.os }}-buildx-${{ github.sha }} - restore-keys: | - ${{ runner.os }}-buildx- - - # 4. Cache npm dependencies - - name: Cache npm dependencies - uses: actions/cache@{{% param "cache_action_version" %}} - with: - path: ~/.npm - key: ${{ runner.os }}-npm-${{ hashFiles('**/package-lock.json') }} - restore-keys: | - ${{ runner.os }}-npm- - - # 5. Extract metadata - - name: Extract metadata - id: meta - run: | - echo "REPO_NAME=${GITHUB_REPOSITORY##*/}" >> "$GITHUB_OUTPUT" - echo "SHORT_SHA=${GITHUB_SHA::7}" >> "$GITHUB_OUTPUT" - - # 6. Build dev Docker image - - name: Build Docker image for tests - uses: docker/build-push-action@{{% param "build_push_action_version" %}} - with: - context: . - file: Dockerfile.dev - tags: ${{ steps.meta.outputs.REPO_NAME }}-dev:latest - load: true - cache-from: type=local,src=/tmp/.buildx-cache - cache-to: type=local,dest=/tmp/.buildx-cache,mode=max - - # 7. Run Angular tests with Jasmine - - name: Run Angular Jasmine tests inside container - run: | - docker run --rm \ - --workdir /app \ - --entrypoint "" \ - ${{ steps.meta.outputs.REPO_NAME }}-dev:latest \ - sh -c "npm ci && npm run test -- --ci --runInBand" - env: - CI: true - NODE_ENV: test - timeout-minutes: 10 - - # 8. Log in to Docker Hub - - name: Log in to Docker Hub - uses: docker/login-action@{{% param "login_action_version" %}} - with: - username: ${{ secrets.DOCKER_USERNAME }} - password: ${{ secrets.DOCKERHUB_TOKEN }} - - # 9. Build and push production image - - name: Build and push production image - uses: docker/build-push-action@{{% param "build_push_action_version" %}} - with: - context: . - file: Dockerfile - push: true - platforms: linux/amd64,linux/arm64 - tags: | - ${{ secrets.DOCKER_USERNAME }}/${{ secrets.DOCKERHUB_PROJECT_NAME }}:latest - ${{ secrets.DOCKER_USERNAME }}/${{ secrets.DOCKERHUB_PROJECT_NAME }}:${{ steps.meta.outputs.SHORT_SHA }} - cache-from: type=local,src=/tmp/.buildx-cache -``` - -This workflow performs the following tasks for your Angular application: -- Triggers on every `push` or `pull request` targeting the `main` branch. -- Builds a development Docker image using `Dockerfile.dev`, optimized for testing. -- Executes unit tests using Vitest inside a clean, containerized environment to ensure consistency. -- Halts the workflow immediately if any test fails — enforcing code quality. -- Caches both Docker build layers and npm dependencies for faster CI runs. -- Authenticates securely with Docker Hub using GitHub repository secrets. -- Builds a production-ready image using the `prod` stage in `Dockerfile`. -- Tags and pushes the final image to Docker Hub with both `latest` and short SHA tags for traceability. - -> [!NOTE] -> For more information about `docker/build-push-action`, refer to the [GitHub Action README](https://github.com/docker/build-push-action/blob/master/README.md). - ---- - -### Step 3: Run the workflow - -After you've added your workflow file, it's time to trigger and observe the CI/CD process in action. - -1. Commit and push your workflow file - - - Select "Commit changes…" in the GitHub editor. - - - This push will automatically trigger the GitHub Actions pipeline. - -2. Monitor the workflow execution - - - Go to the Actions tab in your GitHub repository. - - Click into the workflow run to follow each step: **build**, **test**, and (if successful) **push**. - -3. Verify the Docker image on Docker Hub - - - After a successful workflow run, visit your [Docker Hub repositories](https://hub.docker.com/repositories). - - You should see a new image under your repository with: - - Repository name: `${your-repository-name}` - - Tags include: - - `latest` – represents the most recent successful build; ideal for quick testing or deployment. - - `` – a unique identifier based on the commit hash, useful for version tracking, rollbacks, and traceability. - -> [!TIP] Protect your main branch -> To maintain code quality and prevent accidental direct pushes, enable branch protection rules: -> - Navigate to your **GitHub repo → Settings → Branches**. -> - Under Branch protection rules, click **Add rule**. -> - Specify `main` as the branch name. -> - Enable options like: -> - *Require a pull request before merging*. -> - *Require status checks to pass before merging*. -> -> This ensures that only tested and reviewed code is merged into `main` branch. ---- - -## Summary - -In this section, you set up a complete CI/CD pipeline for your containerized Angular application using GitHub Actions. - -Here's what you accomplished: - -- Created a new GitHub repository specifically for your project. -- Generated a secure Docker Hub access token and added it to GitHub as a secret. -- Defined a GitHub Actions workflow that: - - Build your application inside a Docker container. - - Run tests in a consistent, containerized environment. - - Push a production-ready image to Docker Hub if tests pass. -- Triggered and verified the workflow execution through GitHub Actions. -- Confirmed that your image was successfully published to Docker Hub. - -With this setup, your Angular application is now ready for automated testing and deployment across environments — increasing confidence, consistency, and team productivity. - ---- - -## Related resources - -Deepen your understanding of automation and best practices for containerized apps: - -- [Introduction to GitHub Actions](/guides/gha.md) – Learn how GitHub Actions automate your workflows -- [Docker Build GitHub Actions](/manuals/build/ci/github-actions/_index.md) – Set up container builds with GitHub Actions -- [Workflow syntax for GitHub Actions](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions) – Full reference for writing GitHub workflows -- [Compose file reference](/compose/compose-file/) – Full configuration reference for `compose.yaml` -- [Best practices for writing Dockerfiles](/develop/develop-images/dockerfile_best-practices/) – Optimize your image for performance and security - ---- - -## Next steps - -Next, learn how you can locally test and debug your Angular workloads on Kubernetes before deploying. This helps you ensure your application behaves as expected in a production-like environment, reducing surprises during deployment. diff --git a/content/guides/angular/deploy.md b/content/guides/angular/deploy.md deleted file mode 100644 index f7b938449f73..000000000000 --- a/content/guides/angular/deploy.md +++ /dev/null @@ -1,201 +0,0 @@ ---- -title: Test your Angular deployment -linkTitle: Test your deployment -weight: 60 -keywords: deploy, kubernetes, angular -description: Learn how to deploy locally to test and debug your Kubernetes deployment - ---- - -## Prerequisites - -Before you begin, make sure you’ve completed the following: -- Complete all the previous sections of this guide, starting with [Containerize Angular application](containerize.md). -- [Enable Kubernetes](/manuals/desktop/use-desktop/kubernetes.md#enable-kubernetes) in Docker Desktop. - -> **New to Kubernetes?** -> Visit the [Kubernetes basics tutorial](https://kubernetes.io/docs/tutorials/kubernetes-basics/) to get familiar with how clusters, pods, deployments, and services work. - ---- - -## Overview - -This section guides you through deploying your containerized Angular application locally using [Docker Desktop’s built-in Kubernetes](/desktop/kubernetes/). Running your app in a local Kubernetes cluster closely simulates a real production environment, enabling you to test, validate, and debug your workloads with confidence before promoting them to staging or production. - ---- - -## Create a Kubernetes YAML file - -Follow these steps to define your deployment configuration: - -1. In the root of your project, create a new file named: angular-sample-kubernetes.yaml - -2. Open the file in your IDE or preferred text editor. - -3. Add the following configuration, and be sure to replace `{DOCKER_USERNAME}` and `{DOCKERHUB_PROJECT_NAME}` with your actual Docker Hub username and repository name from the previous [Automate your builds with GitHub Actions](configure-github-actions.md). - - -```yaml -apiVersion: apps/v1 -kind: Deployment -metadata: - name: angular-sample - namespace: default -spec: - replicas: 1 - selector: - matchLabels: - app: angular-sample - template: - metadata: - labels: - app: angular-sample - spec: - containers: - - name: angular-container - image: {DOCKER_USERNAME}/{DOCKERHUB_PROJECT_NAME}:latest - imagePullPolicy: Always - ports: - - containerPort: 8080 - resources: - limits: - cpu: "500m" - memory: "256Mi" - requests: - cpu: "250m" - memory: "128Mi" ---- -apiVersion: v1 -kind: Service -metadata: - name: angular-sample-service - namespace: default -spec: - type: NodePort - selector: - app: angular-sample - ports: - - port: 8080 - targetPort: 8080 - nodePort: 30001 -``` - -This manifest defines two key Kubernetes resources, separated by `---`: - -- Deployment - Deploys a single replica of your Angular application inside a pod. The pod uses the Docker image built and pushed by your GitHub Actions CI/CD workflow - (refer to [Automate your builds with GitHub Actions](configure-github-actions.md)). - The container listens on port `8080`, which is typically used by [Nginx](https://nginx.org/en/docs/) to serve your production Angular app. - -- Service (NodePort) - Exposes the deployed pod to your local machine. - It forwards traffic from port `30001` on your host to port `8080` inside the container. - This lets you access the application in your browser at [http://localhost:30001](http://localhost:30001). - -> [!NOTE] -> To learn more about Kubernetes objects, see the [Kubernetes documentation](https://kubernetes.io/docs/home/). - ---- - -## Deploy and check your application - -Follow these steps to deploy your containerized Angular app into a local Kubernetes cluster and verify that it’s running correctly. - -### Step 1. Apply the Kubernetes configuration - -In your terminal, navigate to the directory where your `angular-sample-kubernetes.yaml` file is located, then deploy the resources using: - -```console - $ kubectl apply -f angular-sample-kubernetes.yaml -``` - -If everything is configured properly, you’ll see confirmation that both the Deployment and the Service were created: - -```shell - deployment.apps/angular-sample created - service/angular-sample-service created -``` - -This confirms that both the Deployment and the Service were successfully created and are now running inside your local cluster. - -### Step 2. Check the deployment status - -Run the following command to check the status of your deployment: - -```console - $ kubectl get deployments -``` - -You should see output similar to the following: - -```shell - NAME READY UP-TO-DATE AVAILABLE AGE - angular-sample 1/1 1 1 14s -``` - -This confirms that your pod is up and running with one replica available. - -### Step 3. Verify the service exposure - -Check if the NodePort service is exposing your app to your local machine: - -```console -$ kubectl get services -``` - -You should see something like: - -```shell -NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE -angular-sample-service NodePort 10.100.185.105 8080:30001/TCP 1m -``` - -This output confirms that your app is available via NodePort on port 30001. - -### Step 4. Access your app in the browser - -Open your browser and navigate to [http://localhost:30001](http://localhost:30001). - -You should see your production-ready Angular Sample application running — served by your local Kubernetes cluster. - -### Step 5. Clean up Kubernetes resources - -Once you're done testing, you can delete the deployment and service using: - -```console - $ kubectl delete -f angular-sample-kubernetes.yaml -``` - -Expected output: - -```shell - deployment.apps "angular-sample" deleted - service "angular-sample-service" deleted -``` - -This ensures your cluster stays clean and ready for the next deployment. - ---- - -## Summary - -In this section, you learned how to deploy your Angular application to a local Kubernetes cluster using Docker Desktop. This setup allows you to test and debug your containerized app in a production-like environment before deploying it to the cloud. - -What you accomplished: - -- Created a Kubernetes Deployment and NodePort Service for your Angular app -- Used `kubectl apply` to deploy the application locally -- Verified the app was running and accessible at `http://localhost:30001` -- Cleaned up your Kubernetes resources after testing - ---- - -## Related resources - -Explore official references and best practices to sharpen your Kubernetes deployment workflow: - -- [Kubernetes documentation](https://kubernetes.io/docs/home/) – Learn about core concepts, workloads, services, and more. -- [Deploy on Kubernetes with Docker Desktop](/manuals/desktop/use-desktop/kubernetes.md) – Use Docker Desktop’s built-in Kubernetes support for local testing and development. -- [`kubectl` CLI reference](https://kubernetes.io/docs/reference/kubectl/) – Manage Kubernetes clusters from the command line. -- [Kubernetes Deployment resource](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/) – Understand how to manage and scale applications using Deployments. -- [Kubernetes Service resource](https://kubernetes.io/docs/concepts/services-networking/service/) – Learn how to expose your application to internal and external traffic. \ No newline at end of file diff --git a/content/guides/angular/run-tests.md b/content/guides/angular/run-tests.md index 309097111465..bed3e0728fe4 100644 --- a/content/guides/angular/run-tests.md +++ b/content/guides/angular/run-tests.md @@ -132,6 +132,3 @@ Explore official references and best practices to sharpen your Docker testing wo - [`docker compose run` CLI reference](/reference/cli/docker/compose/run/) – Run one-off commands in a service container. --- -## Next steps - -Next, you’ll learn how to set up a CI/CD pipeline using GitHub Actions to automatically build and test your Angular application in a containerized environment. This ensures your code is validated on every push or pull request, maintaining consistency and reliability across your development workflow. diff --git a/content/guides/bun/_index.md b/content/guides/bun/_index.md index b50e184c32e1..d05a1139ca05 100644 --- a/content/guides/bun/_index.md +++ b/content/guides/bun/_index.md @@ -21,8 +21,6 @@ The Bun getting started guide teaches you how to create a containerized Bun appl * Containerize and run a Bun application using Docker * Set up a local environment to develop a Bun application using containers -* Configure a CI/CD pipeline for a containerized Bun application using GitHub Actions -* Deploy your containerized application locally to Kubernetes to test and debug your deployment ## Prerequisites diff --git a/content/guides/bun/configure-ci-cd.md b/content/guides/bun/configure-ci-cd.md deleted file mode 100644 index d1c5b9ddc45e..000000000000 --- a/content/guides/bun/configure-ci-cd.md +++ /dev/null @@ -1,132 +0,0 @@ ---- -title: Configure CI/CD for your Bun application -linkTitle: Configure CI/CD -weight: 40 -keywords: ci/cd, github actions, bun, shiny -description: Learn how to configure CI/CD using GitHub Actions for your Bun application. -aliases: -- /language/bun/configure-ci-cd/ ---- - -## Prerequisites - -Complete all the previous sections of this guide, starting with [Containerize a Bun application](containerize.md). You must have a [GitHub](https://github.com/signup) account and a verified [Docker](https://hub.docker.com/signup) account to complete this section. - -## Overview - -In this section, you'll learn how to set up and use GitHub Actions to build and test your Docker image as well as push it to Docker Hub. You will complete the following steps: - -1. Create a new repository on GitHub. -2. Define the GitHub Actions workflow. -3. Run the workflow. - -## Step one: Create the repository - -Create a GitHub repository, configure the Docker Hub credentials, and push your source code. - -1. [Create a new repository](https://github.com/new) on GitHub. - -2. Open the repository **Settings**, and go to **Secrets and variables** > - **Actions**. - -3. Create a new **Repository variable** named `DOCKER_USERNAME` and your Docker ID as a value. - -4. Create a new [Personal Access Token (PAT)](/manuals/security/access-tokens.md#create-an-access-token)for Docker Hub. You can name this token `docker-tutorial`. Make sure access permissions include Read and Write. - -5. Add the PAT as a **Repository secret** in your GitHub repository, with the name - `DOCKERHUB_TOKEN`. - -6. In your local repository on your machine, run the following command to change - the origin to the repository you just created. Make sure you change - `your-username` to your GitHub username and `your-repository` to the name of - the repository you created. - - ```console - $ git remote set-url origin https://github.com/your-username/your-repository.git - ``` - -7. Run the following commands to stage, commit, and push your local repository to GitHub. - - ```console - $ git add -A - $ git commit -m "my commit" - $ git push -u origin main - ``` - -## Step two: Set up the workflow - -Set up your GitHub Actions workflow for building, testing, and pushing the image -to Docker Hub. - -1. Go to your repository on GitHub and then select the **Actions** tab. - -2. Select **set up a workflow yourself**. - - This takes you to a page for creating a new GitHub actions workflow file in - your repository, under `.github/workflows/main.yml` by default. - -3. In the editor window, copy and paste the following YAML configuration and commit the changes. - - ```yaml - name: ci - - on: - push: - branches: - - main - - jobs: - build: - runs-on: ubuntu-latest - steps: - - name: Login to Docker Hub - uses: docker/login-action@{{% param "login_action_version" %}} - with: - username: ${{ vars.DOCKER_USERNAME }} - password: ${{ secrets.DOCKERHUB_TOKEN }} - - - name: Set up Docker Buildx - uses: docker/setup-buildx-action@{{% param "setup_buildx_action_version" %}} - - - name: Build and push - uses: docker/build-push-action@{{% param "build_push_action_version" %}} - with: - platforms: linux/amd64,linux/arm64 - push: true - tags: ${{ vars.DOCKER_USERNAME }}/${{ github.event.repository.name }}:latest - ``` - - For more information about the YAML syntax for `docker/build-push-action`, - refer to the [GitHub Action README](https://github.com/docker/build-push-action/blob/master/README.md). - -## Step three: Run the workflow - -Save the workflow file and run the job. - -1. Select **Commit changes...** and push the changes to the `main` branch. - - After pushing the commit, the workflow starts automatically. - -2. Go to the **Actions** tab. It displays the workflow. - - Selecting the workflow shows you the breakdown of all the steps. - -3. When the workflow is complete, go to your - [repositories on Docker Hub](https://hub.docker.com/repositories). - - If you see the new repository in that list, it means the GitHub Actions - successfully pushed the image to Docker Hub. - -## Summary - -In this section, you learned how to set up a GitHub Actions workflow for your Bun application. - -Related information: - -- [Introduction to GitHub Actions](/guides/gha.md) -- [Docker Build GitHub Actions](/manuals/build/ci/github-actions/_index.md) -- [Workflow syntax for GitHub Actions](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions) - -## Next steps - -Next, learn how you can locally test and debug your workloads on Kubernetes before deploying. diff --git a/content/guides/bun/deploy.md b/content/guides/bun/deploy.md deleted file mode 100644 index 61304b0e158b..000000000000 --- a/content/guides/bun/deploy.md +++ /dev/null @@ -1,141 +0,0 @@ ---- -title: Test your Bun deployment -linkTitle: Test your deployment -weight: 50 -keywords: deploy, kubernetes, bun -description: Learn how to develop locally using Kubernetes -aliases: -- /language/bun/deploy/ ---- - -## Prerequisites - -- Complete all the previous sections of this guide, starting with [Containerize a Bun application](containerize.md). -- [Turn on Kubernetes](/manuals/desktop/use-desktop/kubernetes.md#enable-kubernetes) in Docker Desktop. - -## Overview - -In this section, you'll learn how to use Docker Desktop to deploy your application to a fully-featured Kubernetes environment on your development machine. This allows you to test and debug your workloads on Kubernetes locally before deploying. - -## Create a Kubernetes YAML file - -In your `bun-docker` directory, create a file named -`docker-kubernetes.yml`. Open the file in an IDE or text editor and add -the following contents. Replace `DOCKER_USERNAME/REPO_NAME` with your Docker -username and the name of the repository that you created in [Configure CI/CD for -your Bun application](configure-ci-cd.md). - -```yaml -apiVersion: apps/v1 -kind: Deployment -metadata: - name: docker-bun-demo - namespace: default -spec: - replicas: 1 - selector: - matchLabels: - app: bun-api - template: - metadata: - labels: - app: bun-api - spec: - containers: - - name: bun-api - image: DOCKER_USERNAME/REPO_NAME - imagePullPolicy: Always ---- -apiVersion: v1 -kind: Service -metadata: - name: service-entrypoint - namespace: default -spec: - type: NodePort - selector: - app: bun-api - ports: - - port: 3000 - targetPort: 3000 - nodePort: 30001 -``` - -In this Kubernetes YAML file, there are two objects, separated by the `---`: - - - A Deployment, describing a scalable group of identical pods. In this case, - you'll get just one replica, or copy of your pod. That pod, which is - described under `template`, has just one container in it. The - container is created from the image built by GitHub Actions in [Configure CI/CD for - your Bun application](configure-ci-cd.md). - - A NodePort service, which will route traffic from port 30001 on your host to - port 3000 inside the pods it routes to, allowing you to reach your app - from the network. - -To learn more about Kubernetes objects, see the [Kubernetes documentation](https://kubernetes.io/docs/home/). - -## Deploy and check your application - -1. In a terminal, navigate to `bun-docker` and deploy your application to - Kubernetes. - - ```console - $ kubectl apply -f docker-kubernetes.yml - ``` - - You should see output that looks like the following, indicating your Kubernetes objects were created successfully. - - ```text - deployment.apps/docker-bun-demo created - service/service-entrypoint created - ``` - -2. Make sure everything worked by listing your deployments. - - ```console - $ kubectl get deployments - ``` - - Your deployment should be listed as follows: - - ```shell - NAME READY UP-TO-DATE AVAILABLE AGE - docker-bun-demo 1/1 1 1 10s - ``` - - This indicates all one of the pods you asked for in your YAML are up and running. Do the same check for your services. - - ```console - $ kubectl get services - ``` - - You should get output like the following. - - ```shell - NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE - kubernetes ClusterIP 10.96.0.1 443/TCP 88m - service-entrypoint NodePort 10.105.145.223 3000:30001/TCP 83s - ``` - - In addition to the default `kubernetes` service, you can see your `service-entrypoint` service, accepting traffic on port 30001/TCP. - -3. In a browser, visit the following address. You should see the message `{"Status" : "OK"}`. - - ```console - http://localhost:30001/ - ``` - -4. Run the following command to tear down your application. - - ```console - $ kubectl delete -f docker-kubernetes.yml - ``` - -## Summary - -In this section, you learned how to use Docker Desktop to deploy your Bun application to a fully-featured Kubernetes environment on your development machine. - -Related information: - - [Kubernetes documentation](https://kubernetes.io/docs/home/) - - [Deploy on Kubernetes with Docker Desktop](/manuals/desktop/use-desktop/kubernetes.md) - - [Swarm mode overview](/manuals/engine/swarm/_index.md) diff --git a/content/guides/bun/develop.md b/content/guides/bun/develop.md index 7de9bd63ed7e..bdc37bfa33a8 100644 --- a/content/guides/bun/develop.md +++ b/content/guides/bun/develop.md @@ -70,6 +70,3 @@ Related information: - [Compose file watch](/manuals/compose/how-tos/file-watch.md) - [Multi-stage builds](/manuals/build/building/multi-stage.md) -## Next steps - -In the next section, you'll take a look at how to set up a CI/CD pipeline using GitHub Actions. diff --git a/content/guides/cpp/_index.md b/content/guides/cpp/_index.md index 85f317765e3c..afcd012247de 100644 --- a/content/guides/cpp/_index.md +++ b/content/guides/cpp/_index.md @@ -24,9 +24,6 @@ The C++ getting started guide teaches you how to create a containerized C++ appl - Containerize and run a C++ application using a multi-stage Docker build - Build and run a C++ application using Docker Compose - Set up a local environment to develop a C++ application using containers -- Configure a CI/CD pipeline for a containerized C++ application using GitHub Actions -- Deploy your containerized application locally to Kubernetes to test and debug your deployment -- Use BuildKit to generate SBOM attestations during the build process After completing the C++ getting started modules, you should be able to containerize your own C++ application based on the examples and instructions provided in this guide. diff --git a/content/guides/cpp/configure-ci-cd.md b/content/guides/cpp/configure-ci-cd.md deleted file mode 100644 index e2992f2243b0..000000000000 --- a/content/guides/cpp/configure-ci-cd.md +++ /dev/null @@ -1,133 +0,0 @@ ---- -title: Configure CI/CD for your C++ application -linkTitle: Configure CI/CD -weight: 40 -keywords: ci/cd, github actions, c++, shiny -description: Learn how to configure CI/CD using GitHub Actions for your C++ application. -aliases: - - /language/cpp/configure-ci-cd/ - - /guides/language/cpp/configure-ci-cd/ ---- - -## Prerequisites - -Complete all the previous sections of this guide, starting with [Containerize a C++ application](containerize.md). You must have a [GitHub](https://github.com/signup) account and a verified [Docker](https://hub.docker.com/signup) account to complete this section. - -## Overview - -In this section, you'll learn how to set up and use GitHub Actions to build and test your Docker image as well as push it to Docker Hub. You will complete the following steps: - -1. Create a new repository on GitHub. -2. Define the GitHub Actions workflow. -3. Run the workflow. - -## Step one: Create the repository - -Create a GitHub repository, configure the Docker Hub credentials, and push your source code. - -1. [Create a new repository](https://github.com/new) on GitHub. - -2. Open the repository **Settings**, and go to **Secrets and variables** > - **Actions**. - -3. Create a new **Repository variable** named `DOCKER_USERNAME` and your Docker ID as a value. - -4. Create a new [Personal Access Token (PAT)](/manuals/security/access-tokens.md#create-an-access-token) for Docker Hub. You can name this token `docker-tutorial`. Make sure access permissions include Read and Write. - -5. Add the PAT as a **Repository secret** in your GitHub repository, with the name - `DOCKERHUB_TOKEN`. - -6. In your local repository on your machine, run the following command to change - the origin to the repository you just created. Make sure you change - `your-username` to your GitHub username and `your-repository` to the name of - the repository you created. - - ```console - $ git remote set-url origin https://github.com/your-username/your-repository.git - ``` - -7. Run the following commands to stage, commit, and push your local repository to GitHub. - - ```console - $ git add -A - $ git commit -m "my commit" - $ git push -u origin main - ``` - -## Step two: Set up the workflow - -Set up your GitHub Actions workflow for building, testing, and pushing the image -to Docker Hub. - -1. Go to your repository on GitHub and then select the **Actions** tab. - -2. Select **set up a workflow yourself**. - - This takes you to a page for creating a new GitHub actions workflow file in - your repository, under `.github/workflows/main.yml` by default. - -3. In the editor window, copy and paste the following YAML configuration and commit the changes. - - ```yaml - name: ci - - on: - push: - branches: - - main - - jobs: - build: - runs-on: ubuntu-latest - steps: - - name: Login to Docker Hub - uses: docker/login-action@{{% param "login_action_version" %}} - with: - username: ${{ vars.DOCKER_USERNAME }} - password: ${{ secrets.DOCKERHUB_TOKEN }} - - - name: Set up Docker Buildx - uses: docker/setup-buildx-action@{{% param "setup_buildx_action_version" %}} - - - name: Build and push - uses: docker/build-push-action@{{% param "build_push_action_version" %}} - with: - platforms: linux/amd64,linux/arm64 - push: true - tags: ${{ vars.DOCKER_USERNAME }}/${{ github.event.repository.name }}:latest - ``` - - For more information about the YAML syntax for `docker/build-push-action`, - refer to the [GitHub Action README](https://github.com/docker/build-push-action/blob/master/README.md). - -## Step three: Run the workflow - -Save the workflow file and run the job. - -1. Select **Commit changes...** and push the changes to the `main` branch. - - After pushing the commit, the workflow starts automatically. - -2. Go to the **Actions** tab. It displays the workflow. - - Selecting the workflow shows you the breakdown of all the steps. - -3. When the workflow is complete, go to your - [repositories on Docker Hub](https://hub.docker.com/repositories). - - If you see the new repository in that list, it means the GitHub Actions - successfully pushed the image to Docker Hub. - -## Summary - -In this section, you learned how to set up a GitHub Actions workflow for your C++ application. - -Related information: - -- [Introduction to GitHub Actions](/guides/gha.md) -- [Docker Build GitHub Actions](/manuals/build/ci/github-actions/_index.md) -- [Workflow syntax for GitHub Actions](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions) - -## Next steps - -Next, learn how you can locally test and debug your workloads on Kubernetes before deploying. diff --git a/content/guides/cpp/deploy.md b/content/guides/cpp/deploy.md deleted file mode 100644 index 120067302ba1..000000000000 --- a/content/guides/cpp/deploy.md +++ /dev/null @@ -1,143 +0,0 @@ ---- -title: Test your C++ deployment -linkTitle: Test your deployment -weight: 50 -keywords: deploy, kubernetes, c++ -description: Learn how to develop locally using Kubernetes -aliases: - - /language/cpp/deploy/ - - /guides/language/cpp/deploy/ ---- - -## Prerequisites - -- Complete all the previous sections of this guide, starting with [Containerize a C++ application](containerize.md). -- [Turn on Kubernetes](/manuals/desktop/use-desktop/kubernetes.md#enable-kubernetes) in Docker Desktop. - -## Overview - -In this section, you'll learn how to use Docker Desktop to deploy your application to a fully-featured Kubernetes environment on your development machine. This allows you to test and debug your workloads on Kubernetes locally before deploying. - -## Create a Kubernetes YAML file - -In your `c-plus-plus-docker` directory, create a file named -`docker-kubernetes.yml`. Open the file in an IDE or text editor and add -the following contents. Replace `DOCKER_USERNAME/REPO_NAME` with your Docker -username and the name of the repository that you created in [Configure CI/CD for -your C++ application](configure-ci-cd.md). - -```yaml -apiVersion: apps/v1 -kind: Deployment -metadata: - name: docker-c-plus-plus-demo - namespace: default -spec: - replicas: 1 - selector: - matchLabels: - service: ok-api - template: - metadata: - labels: - service: ok-api - spec: - containers: - - name: ok-api-service - image: DOCKER_USERNAME/REPO_NAME - imagePullPolicy: Always ---- -apiVersion: v1 -kind: Service -metadata: - name: service-entrypoint - namespace: default -spec: - type: NodePort - selector: - service: ok-api - ports: - - port: 8080 - targetPort: 8080 - nodePort: 30001 -``` - -In this Kubernetes YAML file, there are two objects, separated by the `---`: - -- A Deployment, describing a scalable group of identical pods. In this case, - you'll get just one replica, or copy of your pod. That pod, which is - described under `template`, has just one container in it. The - container is created from the image built by GitHub Actions in [Configure CI/CD for - your C++ application](configure-ci-cd.md). -- A NodePort service, which will route traffic from port 30001 on your host to - port 8080 inside the pods it routes to, allowing you to reach your app - from the network. - -To learn more about Kubernetes objects, see the [Kubernetes documentation](https://kubernetes.io/docs/home/). - -## Deploy and check your application - -1. In a terminal, navigate to `c-plus-plus-docker` and deploy your application to - Kubernetes. - - ```console - $ kubectl apply -f docker-kubernetes.yml - ``` - - You should see output that looks like the following, indicating your Kubernetes objects were created successfully. - - ```text - deployment.apps/docker-c-plus-plus-demo created - service/service-entrypoint created - ``` - -2. Make sure everything worked by listing your deployments. - - ```console - $ kubectl get deployments - ``` - - Your deployment should be listed as follows: - - ```shell - NAME READY UP-TO-DATE AVAILABLE AGE - docker-c-plus-plus-demo 1/1 1 1 10s - ``` - - This indicates all one of the pods you asked for in your YAML are up and running. Do the same check for your services. - - ```console - $ kubectl get services - ``` - - You should get output like the following. - - ```shell - NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE - kubernetes ClusterIP 10.96.0.1 443/TCP 88m - service-entrypoint NodePort 10.105.145.223 8080:30001/TCP 83s - ``` - - In addition to the default `kubernetes` service, you can see your `service-entrypoint` service, accepting traffic on port 30001/TCP. - -3. In a browser, visit the following address. You should see the message `{"Status" : "OK"}`. - - ```console - http://localhost:30001/ - ``` - -4. Run the following command to tear down your application. - - ```console - $ kubectl delete -f docker-kubernetes.yml - ``` - -## Summary - -In this section, you learned how to use Docker Desktop to deploy your C++ application to a fully-featured Kubernetes environment on your development machine. - -Related information: - -- [Kubernetes documentation](https://kubernetes.io/docs/home/) -- [Deploy on Kubernetes with Docker Desktop](/manuals/desktop/use-desktop/kubernetes.md) -- [Swarm mode overview](/manuals/engine/swarm/_index.md) diff --git a/content/guides/cpp/develop.md b/content/guides/cpp/develop.md index 016eac56cefa..25da4bfdb8a3 100644 --- a/content/guides/cpp/develop.md +++ b/content/guides/cpp/develop.md @@ -72,6 +72,3 @@ Related information: - [Compose file watch](/manuals/compose/how-tos/file-watch.md) - [Multi-stage builds](/manuals/build/building/multi-stage.md) -## Next steps - -In the next section, you'll take a look at how to set up a CI/CD pipeline using GitHub Actions. diff --git a/content/guides/cpp/security.md b/content/guides/cpp/security.md deleted file mode 100644 index 7318fb5af6d5..000000000000 --- a/content/guides/cpp/security.md +++ /dev/null @@ -1,84 +0,0 @@ ---- -title: Supply-chain security for C++ Docker images -linkTitle: Supply-chain security -weight: 60 -keywords: C++, security, multi-stage -description: Learn how to extract SBOMs from C++ Docker images. -aliases: -- /language/cpp/security/ -- /guides/language/cpp/security/ ---- - -## Prerequisites - -- You have a [Git client](https://git-scm.com/downloads). The examples in this section use a command-line based Git client, but you can use any client. -- You have a Docker Desktop installed, with containerd enabled for pulling and storing images (it's a checkbox in **Settings** > **General**). Otherwise, if you use Docker Engine: - - You have the [Docker Scout CLI plugin](https://docs.docker.com/scout/install/) installed. To install it on Docker Engine, use the following command: - - ```bash - $ curl -sSfL https://raw.githubusercontent.com/docker/scout-cli/main/install.sh | sh -s -- - ``` - - - You have [containerd enabled](https://docs.docker.com/engine/storage/containerd/) for Docker Engine. - -## Overview - -This section walks you through extracting Software Bill of Materials (SBOMs) from a C++ Docker image using Docker Scout. SBOMs provide a detailed list of all the components in a software package, including their versions and licenses. You can use SBOMs to track the provenance of your software and ensure that it complies with your organization's security and licensing policies. - -## Generate an SBOM - -Here we will use the Docker image that we built in the [Create a multi-stage build for your C++ application](/guides/language/cpp/multistage/) guide. If you haven't already built the image, follow the steps in that guide to build the image. -The image is named `hello`. To generate an SBOM for the `hello` image, run the following command: - -```bash -$ docker scout sbom --format list hello -``` - -The command will say "No packages discovered". This is because the final image is a scratch image and doesn't have any packages. - -## Generate an SBOM attestation - -The SBOM can be generated during the build process and "attached" to the image. This is called an SBOM attestation. -To generate an SBOM attestation for the `hello` image, first let's change the Dockerfile: - -```Dockerfile -ARG BUILDKIT_SBOM_SCAN_STAGE=true - -FROM ubuntu:latest AS build - -RUN apt-get update && apt-get install -y build-essential - -WORKDIR /app - -COPY hello.cpp . - -RUN g++ -o hello hello.cpp -static - -# -------------------- -FROM scratch - -COPY --from=build /app/hello /hello - -CMD ["/hello"] -``` - -The first line `ARG BUILDKIT_SBOM_SCAN_STAGE=true` enables SBOM scanning in the build stage. -Now, build the image with the following command: - -```bash -$ docker buildx build --sbom=true -t hello:sbom . -``` - -This command will build the image and generate an SBOM attestation. You can verify that the SBOM is attached to the image by running the following command: - -```bash -$ docker scout sbom --format list hello:sbom -``` - -Docker Scout reads the SBOM attestation when one is available, so this command reports packages from the build-stage metadata instead of indexing only the final scratch image filesystem. - -## Summary - -In this section, you learned how to generate SBOM attestation for a C++ Docker image during the build process. -Image scanners that inspect only the final filesystem may not identify packages in scratch images. -Use SBOM attestations to preserve package metadata from the build. diff --git a/content/guides/deno/_index.md b/content/guides/deno/_index.md index f2a9dc38b715..05fca9568f96 100644 --- a/content/guides/deno/_index.md +++ b/content/guides/deno/_index.md @@ -22,8 +22,6 @@ The Deno getting started guide teaches you how to create a containerized Deno ap * Containerize and run a Deno application using Docker * Set up a local environment to develop a Deno application using containers * Use Docker Compose to run the application. -* Configure a CI/CD pipeline for a containerized Deno application using GitHub Actions -* Deploy your containerized application locally to Kubernetes to test and debug your deployment ## Prerequisites diff --git a/content/guides/deno/configure-ci-cd.md b/content/guides/deno/configure-ci-cd.md deleted file mode 100644 index 8d62f21be40a..000000000000 --- a/content/guides/deno/configure-ci-cd.md +++ /dev/null @@ -1,131 +0,0 @@ ---- -title: Configure CI/CD for your Deno application -linkTitle: Configure CI/CD -weight: 40 -keywords: ci/cd, github actions, deno, shiny -description: Learn how to configure CI/CD using GitHub Actions for your Deno application. -aliases: -- /language/deno/configure-ci-cd/ ---- - -## Prerequisites - -Complete all the previous sections of this guide, starting with [Containerize a Deno application](containerize.md). You must have a [GitHub](https://github.com/signup) account and a verified [Docker](https://hub.docker.com/signup) account to complete this section. - -## Overview - -In this section, you'll learn how to set up and use GitHub Actions to build and test your Docker image as well as push it to Docker Hub. You will complete the following steps: - -1. Create a new repository on GitHub. -2. Define the GitHub Actions workflow. -3. Run the workflow. - -## Step one: Create the repository - -Create a GitHub repository, configure the Docker Hub credentials, and push your source code. - -1. [Create a new repository](https://github.com/new) on GitHub. - -2. Open the repository **Settings**, and go to **Secrets and variables** > - **Actions**. - -3. Create a new **Repository variable** named `DOCKER_USERNAME` and your Docker ID as a value. - -4. Create a new [Personal Access Token (PAT)](/manuals/security/access-tokens.md#create-an-access-token)for Docker Hub. You can name this token `docker-tutorial`. Make sure access permissions include Read and Write. - -5. Add the PAT as a **Repository secret** in your GitHub repository, with the name - `DOCKERHUB_TOKEN`. - -6. In your local repository on your machine, run the following command to change - the origin to the repository you just created. Make sure you change - `your-username` to your GitHub username and `your-repository` to the name of - the repository you created. - - ```console - $ git remote set-url origin https://github.com/your-username/your-repository.git - ``` - -7. Run the following commands to stage, commit, and push your local repository to GitHub. - - ```console - $ git add -A - $ git commit -m "my commit" - $ git push -u origin main - ``` - -## Step two: Set up the workflow - -Set up your GitHub Actions workflow for building and pushing the image -to Docker Hub. - -1. Go to your repository on GitHub and then select the **Actions** tab. - -2. Select **set up a workflow yourself**. - - This takes you to a page for creating a new GitHub actions workflow file in - your repository, under `.github/workflows/main.yml` by default. - -3. In the editor window, copy and paste the following YAML configuration and commit the changes. - - ```yaml - name: ci - - on: - push: - branches: - - main - - jobs: - build: - runs-on: ubuntu-latest - steps: - - - name: Login to Docker Hub - uses: docker/login-action@{{% param "login_action_version" %}} - with: - username: ${{ vars.DOCKER_USERNAME }} - password: ${{ secrets.DOCKERHUB_TOKEN }} - - - name: Set up Docker Buildx - uses: docker/setup-buildx-action@{{% param "setup_buildx_action_version" %}} - - - name: Build and push - uses: docker/build-push-action@{{% param "build_push_action_version" %}} - with: - platforms: linux/amd64,linux/arm64 - push: true - tags: ${{ vars.DOCKER_USERNAME }}/${{ github.event.repository.name }}:latest - ``` - - For more information about the YAML syntax for `docker/build-push-action`, - refer to the [GitHub Action README](https://github.com/docker/build-push-action/blob/master/README.md). - -## Step three: Run the workflow - -Save the workflow file and run the job. - -1. Select **Commit changes...** and push the changes to the `main` branch. - - After pushing the commit, the workflow starts automatically. - -2. Go to the **Actions** tab. It displays the workflow. - - Selecting the workflow shows you the breakdown of all the steps. - -3. When the workflow is complete, go to your - [repositories on Docker Hub](https://hub.docker.com/repositories). - - If you see the new repository in that list, it means the GitHub Actions - successfully pushed the image to Docker Hub. - -## Summary - -In this section, you learned how to set up a GitHub Actions workflow for your Deno application. - -Related information: - - [Introduction to GitHub Actions](/manuals/build/ci/github-actions/_index.md) - - [Workflow syntax for GitHub Actions](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions) - -## Next steps - -Next, learn how you can locally test and debug your workloads on Kubernetes before deploying. diff --git a/content/guides/deno/deploy.md b/content/guides/deno/deploy.md deleted file mode 100644 index 7e00828ec9f1..000000000000 --- a/content/guides/deno/deploy.md +++ /dev/null @@ -1,141 +0,0 @@ ---- -title: Test your Deno deployment -linkTitle: Test your deployment -weight: 50 -keywords: deploy, kubernetes, deno -description: Learn how to develop locally using Kubernetes -aliases: -- /language/deno/deploy/ ---- - -## Prerequisites - -- Complete all the previous sections of this guide, starting with [Containerize a Deno application](containerize.md). -- [Turn on Kubernetes](/manuals//desktop/use-desktop/kubernetes.md#enable-kubernetes) in Docker Desktop. - -## Overview - -In this section, you'll learn how to use Docker Desktop to deploy your application to a fully-featured Kubernetes environment on your development machine. This allows you to test and debug your workloads on Kubernetes locally before deploying. - -## Create a Kubernetes YAML file - -In your `deno-docker` directory, create a file named -`docker-kubernetes.yml`. Open the file in an IDE or text editor and add -the following contents. Replace `DOCKER_USERNAME/REPO_NAME` with your Docker -username and the name of the repository that you created in [Configure CI/CD for -your Deno application](configure-ci-cd.md). - -```yaml -apiVersion: apps/v1 -kind: Deployment -metadata: - name: docker-deno-demo - namespace: default -spec: - replicas: 1 - selector: - matchLabels: - app: deno-api - template: - metadata: - labels: - app: deno-api - spec: - containers: - - name: deno-api - image: DOCKER_USERNAME/REPO_NAME - imagePullPolicy: Always ---- -apiVersion: v1 -kind: Service -metadata: - name: service-entrypoint - namespace: default -spec: - type: NodePort - selector: - app: deno-api - ports: - - port: 8000 - targetPort: 8000 - nodePort: 30001 -``` - -In this Kubernetes YAML file, there are two objects, separated by the `---`: - - - A Deployment, describing a scalable group of identical pods. In this case, - you'll get just one replica, or copy of your pod. That pod, which is - described under `template`, has just one container in it. The - container is created from the image built by GitHub Actions in [Configure CI/CD for - your Deno application](configure-ci-cd.md). - - A NodePort service, which will route traffic from port 30001 on your host to - port 8000 inside the pods it routes to, allowing you to reach your app - from the network. - -To learn more about Kubernetes objects, see the [Kubernetes documentation](https://kubernetes.io/docs/home/). - -## Deploy and check your application - -1. In a terminal, navigate to `deno-docker` and deploy your application to - Kubernetes. - - ```console - $ kubectl apply -f docker-kubernetes.yml - ``` - - You should see output that looks like the following, indicating your Kubernetes objects were created successfully. - - ```text - deployment.apps/docker-deno-demo created - service/service-entrypoint created - ``` - -2. Make sure everything worked by listing your deployments. - - ```console - $ kubectl get deployments - ``` - - Your deployment should be listed as follows: - - ```shell - NAME READY UP-TO-DATE AVAILABLE AGE - docker-deno-demo 1/1 1 1 10s - ``` - - This indicates all one of the pods you asked for in your YAML are up and running. Do the same check for your services. - - ```console - $ kubectl get services - ``` - - You should get output like the following. - - ```shell - NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE - kubernetes ClusterIP 10.96.0.1 443/TCP 88m - service-entrypoint NodePort 10.105.145.223 8000:30001/TCP 83s - ``` - - In addition to the default `kubernetes` service, you can see your `service-entrypoint` service, accepting traffic on port 30001/TCP. - -3. In a browser, visit the following address. You should see the message `{"Status" : "OK"}`. - - ```console - http://localhost:30001/ - ``` - -4. Run the following command to tear down your application. - - ```console - $ kubectl delete -f docker-kubernetes.yml - ``` - -## Summary - -In this section, you learned how to use Docker Desktop to deploy your Deno application to a fully-featured Kubernetes environment on your development machine. - -Related information: - - [Kubernetes documentation](https://kubernetes.io/docs/home/) - - [Deploy on Kubernetes with Docker Desktop](/manuals/desktop/use-desktop/kubernetes.md) - - [Swarm mode overview](/manuals/engine/swarm/_index.md) diff --git a/content/guides/deno/develop.md b/content/guides/deno/develop.md index d717823b634d..339b07f10ad7 100644 --- a/content/guides/deno/develop.md +++ b/content/guides/deno/develop.md @@ -70,6 +70,3 @@ Related information: - [Compose file watch](/manuals/compose/how-tos/file-watch.md) - [Multi-stage builds](/manuals/build/building/multi-stage.md) -## Next steps - -In the next section, you'll take a look at how to set up a CI/CD pipeline using GitHub Actions. diff --git a/content/guides/dotnet/_index.md b/content/guides/dotnet/_index.md index 849c17f2b636..ebc4245469fc 100644 --- a/content/guides/dotnet/_index.md +++ b/content/guides/dotnet/_index.md @@ -20,8 +20,6 @@ The .NET getting started guide teaches you how to create a containerized .NET ap - Containerize and run a .NET application - Set up a local environment to develop a .NET application using containers - Run tests for a .NET application using containers -- Configure a CI/CD pipeline for a containerized .NET application using GitHub Actions -- Deploy your containerized application locally to Kubernetes to test and debug your deployment After completing the .NET getting started modules, you should be able to containerize your own .NET application based on the examples and instructions provided in this guide. diff --git a/content/guides/dotnet/configure-ci-cd.md b/content/guides/dotnet/configure-ci-cd.md deleted file mode 100644 index b5065330ef9f..000000000000 --- a/content/guides/dotnet/configure-ci-cd.md +++ /dev/null @@ -1,148 +0,0 @@ ---- -title: Configure CI/CD for your .NET application -linkTitle: Configure CI/CD -weight: 40 -keywords: .net, CI/CD -description: Learn how to Configure CI/CD for your .NET application -aliases: - - /language/dotnet/configure-ci-cd/ - - /guides/language/dotnet/configure-ci-cd/ ---- - -## Prerequisites - -Complete all the previous sections of this guide, starting with [Containerize a .NET application](containerize.md). You must have a [GitHub](https://github.com/signup) account and a verified [Docker](https://hub.docker.com/signup) account to complete this section. - -## Overview - -In this section, you'll learn how to set up and use GitHub Actions to build and test your Docker image as well as push it to Docker Hub. You will complete the following steps: - -1. Create a new repository on GitHub. -2. Define the GitHub Actions workflow. -3. Run the workflow. - -## Step one: Create the repository - -Create a GitHub repository, configure the Docker Hub credentials, and push your source code. - -1. [Create a new repository](https://github.com/new) on GitHub. - -2. Open the repository **Settings**, and go to **Secrets and variables** > - **Actions**. - -3. Create a new **Repository variable** named `DOCKER_USERNAME` and your Docker ID as a value. - -4. Create a new [Personal Access Token (PAT)](/manuals/security/access-tokens.md#create-an-access-token) for Docker Hub. You can name this token `docker-tutorial`. Make sure access permissions include Read and Write. - -5. Add the PAT as a **Repository secret** in your GitHub repository, with the name - `DOCKERHUB_TOKEN`. - -6. In your local repository on your machine, run the following command to change - the origin to the repository you just created. Make sure you change - `your-username` to your GitHub username and `your-repository` to the name of - the repository you created. - - ```console - $ git remote set-url origin https://github.com/your-username/your-repository.git - ``` - -7. In your local repository on your machine, run the following command to rename - the branch to main. - - ```console - $ git branch -M main - ``` - -8. Run the following commands to stage, commit, and then push your local - repository to GitHub. - - ```console - $ git add -A - $ git commit -m "my first commit" - $ git push -u origin main - ``` - -## Step two: Set up the workflow - -Set up your GitHub Actions workflow for building, testing, and pushing the image -to Docker Hub. - -1. Go to your repository on GitHub and then select the **Actions** tab. - -2. Select **set up a workflow yourself**. - - This takes you to a page for creating a new GitHub actions workflow file in - your repository, under `.github/workflows/main.yml` by default. - -3. In the editor window, copy and paste the following YAML configuration. - - ```yaml - name: ci - - on: - push: - branches: - - main - - jobs: - build: - runs-on: ubuntu-latest - steps: - - name: Login to Docker Hub - uses: docker/login-action@{{% param "login_action_version" %}} - with: - username: ${{ vars.DOCKER_USERNAME }} - password: ${{ secrets.DOCKERHUB_TOKEN }} - - - name: Set up Docker Buildx - uses: docker/setup-buildx-action@{{% param "setup_buildx_action_version" %}} - - - name: Build and test - uses: docker/build-push-action@{{% param "build_push_action_version" %}} - with: - target: build - load: true - - - name: Build and push - uses: docker/build-push-action@{{% param "build_push_action_version" %}} - with: - platforms: linux/amd64,linux/arm64 - push: true - target: final - tags: ${{ vars.DOCKER_USERNAME }}/${{ github.event.repository.name }}:latest - ``` - - For more information about the YAML syntax for `docker/build-push-action`, - refer to the [GitHub Action README](https://github.com/docker/build-push-action/blob/master/README.md). - -## Step three: Run the workflow - -Save the workflow file and run the job. - -1. Select **Commit changes...** and push the changes to the `main` branch. - - After pushing the commit, the workflow starts automatically. - -2. Go to the **Actions** tab. It displays the workflow. - - Selecting the workflow shows you the breakdown of all the steps. - -3. When the workflow is complete, go to your - [repositories on Docker Hub](https://hub.docker.com/repositories). - - If you see the new repository in that list, it means the GitHub Actions - successfully pushed the image to Docker Hub. - -## Summary - -In this section, you learned how to set up a GitHub Actions workflow for your application. - -Related information: - -- [Introduction to GitHub Actions](/guides/gha.md) -- [Docker Build GitHub Actions](/manuals/build/ci/github-actions/_index.md) -- [Workflow syntax for GitHub Actions](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions) - -## Next steps - -Next, learn how you can locally test and debug your workloads on Kubernetes before deploying. diff --git a/content/guides/dotnet/deploy.md b/content/guides/dotnet/deploy.md deleted file mode 100644 index 0f4089ab88c5..000000000000 --- a/content/guides/dotnet/deploy.md +++ /dev/null @@ -1,224 +0,0 @@ ---- -title: Test your .NET deployment -linkTitle: Test your deployment -weight: 50 -keywords: deploy, .net, local, development -description: Learn how to deploy your application -aliases: - - /language/dotnet/deploy/ - - /guides/language/dotnet/deploy/ ---- - -## Prerequisites - -- Complete all the previous sections of this guide, starting with [Containerize - a .NET application](containerize.md). -- [Turn on Kubernetes](/manuals/desktop/use-desktop/kubernetes.md#enable-kubernetes) in Docker - Desktop. - -## Overview - -In this section, you'll learn how to use Docker Desktop to deploy your -application to a fully-featured Kubernetes environment on your development -machine. This allows you to test and debug your workloads on Kubernetes locally -before deploying. - -## Create a Kubernetes YAML file - -In your `docker-dotnet-sample` directory, create a file named -`docker-dotnet-kubernetes.yaml`. Open the file in an IDE or text editor and add -the following contents. Replace `DOCKER_USERNAME/REPO_NAME` with your Docker -username and the name of the repository that you created in [Configure CI/CD for -your .NET application](configure-ci-cd.md). - -```yaml -apiVersion: apps/v1 -kind: Deployment -metadata: - labels: - service: server - name: server - namespace: default -spec: - replicas: 1 - selector: - matchLabels: - service: server - strategy: {} - template: - metadata: - labels: - service: server - spec: - initContainers: - - name: wait-for-db - image: busybox:1.28 - command: - [ - "sh", - "-c", - 'until nc -zv db 5432; do echo "waiting for db"; sleep 2; done;', - ] - containers: - - image: DOCKER_USERNAME/REPO_NAME - name: server - imagePullPolicy: Always - ports: - - containerPort: 8080 - hostPort: 8080 - protocol: TCP - resources: {} - restartPolicy: Always -status: {} ---- -apiVersion: apps/v1 -kind: Deployment -metadata: - labels: - service: db - name: db - namespace: default -spec: - replicas: 1 - selector: - matchLabels: - service: db - strategy: - type: Recreate - template: - metadata: - labels: - service: db - spec: - containers: - - env: - - name: POSTGRES_DB - value: example - - name: POSTGRES_PASSWORD - value: example - image: postgres:18 - name: db - ports: - - containerPort: 5432 - protocol: TCP - resources: {} - restartPolicy: Always -status: {} ---- -apiVersion: v1 -kind: Service -metadata: - labels: - service: server - name: server - namespace: default -spec: - type: NodePort - ports: - - name: "8080" - port: 8080 - targetPort: 8080 - nodePort: 30001 - selector: - service: server -status: - loadBalancer: {} ---- -apiVersion: v1 -kind: Service -metadata: - labels: - service: db - name: db - namespace: default -spec: - ports: - - name: "5432" - port: 5432 - targetPort: 5432 - selector: - service: db -status: - loadBalancer: {} -``` - -In this Kubernetes YAML file, there are four objects, separated by the `---`. In addition to a Service and Deployment for the database, the other two objects are: - -- A Deployment, describing a scalable group of identical pods. In this case, - you'll get just one replica, or copy of your pod. That pod, which is - described under `template`, has just one container in it. The container is - created from the image built by GitHub Actions in [Configure CI/CD for your - .NET application](configure-ci-cd.md). -- A NodePort service, which will route traffic from port 30001 on your host to - port 8080 inside the pods it routes to, allowing you to reach your app - from the network. - -To learn more about Kubernetes objects, see the [Kubernetes documentation](https://kubernetes.io/docs/home/). - -## Deploy and check your application - -1. In a terminal, navigate to the `docker-dotnet-sample` directory - and deploy your application to Kubernetes. - - ```console - $ kubectl apply -f docker-dotnet-kubernetes.yaml - ``` - - You should see output that looks like the following, indicating your Kubernetes objects were created successfully. - - ```shell - deployment.apps/db created - service/db created - deployment.apps/server created - service/server created - ``` - -2. Make sure everything worked by listing your deployments. - - ```console - $ kubectl get deployments - ``` - - Your deployment should be listed as follows: - - ```shell - NAME READY UP-TO-DATE AVAILABLE AGE - db 1/1 1 1 76s - server 1/1 1 1 76s - ``` - - This indicates all of the pods are up and running. Do the same check for your services. - - ```console - $ kubectl get services - ``` - - You should get output like the following. - - ```shell - NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE - db ClusterIP 10.96.156.90 5432/TCP 2m8s - kubernetes ClusterIP 10.96.0.1 443/TCP 164m - server NodePort 10.102.94.225 8080:30001/TCP 2m8s - ``` - - In addition to the default `kubernetes` service, you can see your `server` service and `db` service. The `server` service is accepting traffic on port 30001/TCP. - -3. Open a browser and visit your app at `localhost:30001`. You should see your - application. - -4. Run the following command to tear down your application. - - ```console - $ kubectl delete -f docker-dotnet-kubernetes.yaml - ``` - -## Summary - -In this section, you learned how to use Docker Desktop to deploy your application to a fully-featured Kubernetes environment on your development machine. - -Related information: - -- [Kubernetes documentation](https://kubernetes.io/docs/home/) -- [Deploy on Kubernetes with Docker Desktop](/manuals/desktop/use-desktop/kubernetes.md) -- [Swarm mode overview](/manuals/engine/swarm/_index.md) diff --git a/content/guides/dotnet/run-tests.md b/content/guides/dotnet/run-tests.md index 196a7b6311c6..5fb73db9806a 100644 --- a/content/guides/dotnet/run-tests.md +++ b/content/guides/dotnet/run-tests.md @@ -144,6 +144,3 @@ Related information: - [docker compose run](/reference/cli/docker/compose/run/) -## Next steps - -Next, you’ll learn how to set up a CI/CD pipeline using GitHub Actions. diff --git a/content/guides/golang/_index.md b/content/guides/golang/_index.md index 7d63660706a7..c95c992d7444 100644 --- a/content/guides/golang/_index.md +++ b/content/guides/golang/_index.md @@ -29,8 +29,6 @@ In this guide, you’ll learn how to: - Run the image as a container in your local Docker instance and manage the container's lifecycle. - Use multi-stage builds for building small images efficiently while keeping your Dockerfiles easy to read and maintain. - Use Docker Compose to orchestrate running of multiple related containers together in a development environment. -- Configure a CI/CD pipeline for your application using [GitHub Actions](https://docs.github.com/en/actions) -- Deploy your containerized Go application. ## Prerequisites diff --git a/content/guides/golang/configure-ci-cd.md b/content/guides/golang/configure-ci-cd.md deleted file mode 100644 index 2f1f12a57c9d..000000000000 --- a/content/guides/golang/configure-ci-cd.md +++ /dev/null @@ -1,133 +0,0 @@ ---- -title: Configure CI/CD for your Go application -linkTitle: Configure CI/CD -weight: 40 -keywords: go, CI/CD, local, development -description: Learn how to Configure CI/CD for your Go application -aliases: - - /language/golang/configure-ci-cd/ - - /guides/language/golang/configure-ci-cd/ ---- - -## Prerequisites - -Complete the previous sections of this guide, starting with [Build your Go image](build-images.md). You must have a [GitHub](https://github.com/signup) account and a verified [Docker](https://hub.docker.com/signup) account to complete this section. - -## Overview - -In this section, you'll learn how to set up and use GitHub Actions to build and push your Docker image to Docker Hub. You will complete the following steps: - -1. Create a new repository on GitHub. -2. Define the GitHub Actions workflow. -3. Run the workflow. - -## Step one: Create the repository - -Create a GitHub repository, configure the Docker Hub credentials, and push your source code. - -1. [Create a new repository](https://github.com/new) on GitHub. - -2. Open the repository **Settings**, and go to **Secrets and variables** > - **Actions**. - -3. Create a new **Repository variable** named `DOCKER_USERNAME` and your Docker ID as a value. - -4. Create a new [Personal Access Token (PAT)](/manuals/security/access-tokens.md#create-an-access-token) for Docker Hub. You can name this token `docker-tutorial`. Make sure access permissions include Read and Write. - -5. Add the PAT as a **Repository secret** in your GitHub repository, with the name - `DOCKERHUB_TOKEN`. - -6. In your local repository on your machine, run the following command to change - the origin to the repository you just created. Make sure you change - `your-username` to your GitHub username and `your-repository` to the name of - the repository you created. - - ```console - $ git remote set-url origin https://github.com/your-username/your-repository.git - ``` - -7. Run the following commands to stage, commit, and push your local repository to GitHub. - - ```console - $ git add -A - $ git commit -m "my commit" - $ git push -u origin main - ``` - -## Step two: Set up the workflow - -Set up your GitHub Actions workflow for building, testing, and pushing the image -to Docker Hub. - -1. Go to your repository on GitHub and then select the **Actions** tab. - -2. Select **set up a workflow yourself**. - - This takes you to a page for creating a new GitHub actions workflow file in - your repository, under `.github/workflows/main.yml` by default. - -3. In the editor window, copy and paste the following YAML configuration and commit the changes. - - ```yaml - name: ci - - on: - push: - branches: - - main - - jobs: - build: - runs-on: ubuntu-latest - steps: - - name: Login to Docker Hub - uses: docker/login-action@{{% param "login_action_version" %}} - with: - username: ${{ vars.DOCKER_USERNAME }} - password: ${{ secrets.DOCKERHUB_TOKEN }} - - - name: Set up Docker Buildx - uses: docker/setup-buildx-action@{{% param "setup_buildx_action_version" %}} - - - name: Build and push - uses: docker/build-push-action@{{% param "build_push_action_version" %}} - with: - platforms: linux/amd64,linux/arm64 - push: true - tags: ${{ vars.DOCKER_USERNAME }}/${{ github.event.repository.name }}:latest - ``` - - For more information about the YAML syntax for `docker/build-push-action`, - refer to the [GitHub Action README](https://github.com/docker/build-push-action/blob/master/README.md). - -## Step three: Run the workflow - -Save the workflow file and run the job. - -1. Select **Commit changes...** and push the changes to the `main` branch. - - After pushing the commit, the workflow starts automatically. - -2. Go to the **Actions** tab. It displays the workflow. - - Selecting the workflow shows you the breakdown of all the steps. - -3. When the workflow is complete, go to your - [repositories on Docker Hub](https://hub.docker.com/repositories). - - If you see the new repository in that list, it means the GitHub Actions - successfully pushed the image to Docker Hub. - -## Summary - -In this section, you learned how to set up a GitHub Actions workflow for your application. - -Related information: - -- [Introduction to GitHub Actions](/guides/gha.md) -- [Docker Build GitHub Actions](/manuals/build/ci/github-actions/_index.md) -- [Workflow syntax for GitHub Actions](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions) - -## Next steps - -Next, learn how you can locally test and debug your workloads on Kubernetes before deploying. diff --git a/content/guides/golang/deploy.md b/content/guides/golang/deploy.md deleted file mode 100644 index 1002d6e3d1a9..000000000000 --- a/content/guides/golang/deploy.md +++ /dev/null @@ -1,249 +0,0 @@ ---- -title: Test your Go deployment -linkTitle: Test your deployment -weight: 50 -keywords: deploy, go, local, development -description: Learn how to deploy your Go application -aliases: - - /language/golang/deploy/ - - /guides/language/golang/deploy/ ---- - -## Prerequisites - -- Complete all the previous sections of this guide, starting with [Build - your Go image](build-images.md). -- [Turn on Kubernetes](/manuals/desktop/use-desktop/kubernetes.md#enable-kubernetes) in Docker - Desktop. - -## Overview - -In this section, you'll learn how to use Docker Desktop to deploy your -application to a fully-featured Kubernetes environment on your development -machine. This allows you to test and debug your workloads on Kubernetes locally -before deploying. - -## Create a Kubernetes YAML file - -In your project directory, create a file named -`docker-go-kubernetes.yaml`. Open the file in an IDE or text editor and add -the following contents. Replace `DOCKER_USERNAME/REPO_NAME` with your Docker -username and the name of the repository that you created in [Configure CI/CD for -your Go application](configure-ci-cd.md). - -```yaml -apiVersion: apps/v1 -kind: Deployment -metadata: - labels: - service: server - name: server - namespace: default -spec: - replicas: 1 - selector: - matchLabels: - service: server - strategy: {} - template: - metadata: - labels: - service: server - spec: - initContainers: - - name: wait-for-db - image: busybox:1.28 - command: - [ - "sh", - "-c", - 'until nc -zv db 5432; do echo "waiting for db"; sleep 2; done;', - ] - containers: - - env: - - name: PGDATABASE - value: mydb - - name: PGPASSWORD - value: whatever - - name: PGHOST - value: db - - name: PGPORT - value: "5432" - - name: PGUSER - value: postgres - image: DOCKER_USERNAME/REPO_NAME - name: server - imagePullPolicy: Always - ports: - - containerPort: 8080 - hostPort: 8080 - protocol: TCP - resources: {} - restartPolicy: Always -status: {} ---- -apiVersion: apps/v1 -kind: Deployment -metadata: - labels: - service: db - name: db - namespace: default -spec: - replicas: 1 - selector: - matchLabels: - service: db - strategy: - type: Recreate - template: - metadata: - labels: - service: db - spec: - containers: - - env: - - name: POSTGRES_DB - value: mydb - - name: POSTGRES_PASSWORD - value: whatever - - name: POSTGRES_USER - value: postgres - image: postgres:18 - name: db - ports: - - containerPort: 5432 - protocol: TCP - resources: {} - restartPolicy: Always -status: {} ---- -apiVersion: v1 -kind: Service -metadata: - labels: - service: server - name: server - namespace: default -spec: - type: NodePort - ports: - - name: "8080" - port: 8080 - targetPort: 8080 - nodePort: 30001 - selector: - service: server -status: - loadBalancer: {} ---- -apiVersion: v1 -kind: Service -metadata: - labels: - service: db - name: db - namespace: default -spec: - ports: - - name: "5432" - port: 5432 - targetPort: 5432 - selector: - service: db -status: - loadBalancer: {} -``` - -In this Kubernetes YAML file, there are four objects, separated by the `---`. In addition to a Service and Deployment for the database, the other two objects are: - -- A Deployment, describing a scalable group of identical pods. In this case, - you'll get just one replica, or copy of your pod. That pod, which is - described under `template`, has just one container in it. The container is - created from the image built by GitHub Actions in [Configure CI/CD for your - Go application](configure-ci-cd.md). -- A NodePort service, which will route traffic from port 30001 on your host to - port 8080 inside the pods it routes to, allowing you to reach your app - from the network. - -To learn more about Kubernetes objects, see the [Kubernetes documentation](https://kubernetes.io/docs/home/). - -## Deploy and check your application - -1. In a terminal, navigate to the project directory - and deploy your application to Kubernetes. - - ```console - $ kubectl apply -f docker-go-kubernetes.yaml - ``` - - You should see output that looks like the following, indicating your Kubernetes objects were created successfully. - - ```shell - deployment.apps/db created - service/db created - deployment.apps/server created - service/server created - ``` - -2. Make sure everything worked by listing your deployments. - - ```console - $ kubectl get deployments - ``` - - Your deployment should be listed as follows: - - ```shell - NAME READY UP-TO-DATE AVAILABLE AGE - db 1/1 1 1 76s - server 1/1 1 1 76s - ``` - - This indicates all of the pods are up and running. Do the same check for your services. - - ```console - $ kubectl get services - ``` - - You should get output like the following. - - ```shell - NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE - db ClusterIP 10.96.156.90 5432/TCP 2m8s - kubernetes ClusterIP 10.96.0.1 443/TCP 164m - server NodePort 10.102.94.225 8080:30001/TCP 2m8s - ``` - - In addition to the default `kubernetes` service, you can see your `server` service and `db` service. The `server` service is accepting traffic on port 30001/TCP. - -3. Open a terminal and curl your application to verify that it's working. - - ```console - $ curl --request POST \ - --url http://localhost:30001/send \ - --header 'content-type: application/json' \ - --data '{"value": "Hello, Oliver!"}' - ``` - - You should get the following message back. - - ```json - { "value": "Hello, Oliver!" } - ``` - -4. Run the following command to tear down your application. - - ```console - $ kubectl delete -f docker-go-kubernetes.yaml - ``` - -## Summary - -In this section, you learned how to use Docker Desktop to deploy your application to a fully-featured Kubernetes environment on your development machine. - -Related information: - -- [Kubernetes documentation](https://kubernetes.io/docs/home/) -- [Deploy on Kubernetes with Docker Desktop](/manuals/desktop/use-desktop/kubernetes.md) -- [Swarm mode overview](/manuals/engine/swarm/_index.md) diff --git a/content/guides/golang/run-tests.md b/content/guides/golang/run-tests.md index b4b435fd62e2..f53b2c2ad842 100644 --- a/content/guides/golang/run-tests.md +++ b/content/guides/golang/run-tests.md @@ -90,7 +90,3 @@ You should see output containing the following. #13 4.915 PASS ``` -## Next steps - -In this section, you learned how to run tests when building your image. Next, -you’ll learn how to set up a CI/CD pipeline using GitHub Actions. diff --git a/content/guides/java/_index.md b/content/guides/java/_index.md index b605ffd48457..748576a56c7f 100644 --- a/content/guides/java/_index.md +++ b/content/guides/java/_index.md @@ -20,8 +20,6 @@ The Java getting started guide teaches you how to create a containerized Spring - Containerize and run a Spring Boot application with Maven - Set up a local development environment to connect a database to the container, configure a debugger, and use Compose Watch for live reload - Run your unit tests inside a container -- Configure a CI/CD pipeline for your application using GitHub Actions -- Deploy your containerized application locally to Kubernetes to test and debug your deployment After completing the Java getting started modules, you should be able to containerize your own Java application based on the examples and instructions provided in this guide. diff --git a/content/guides/java/configure-ci-cd.md b/content/guides/java/configure-ci-cd.md deleted file mode 100644 index ee6c0cd41bf7..000000000000 --- a/content/guides/java/configure-ci-cd.md +++ /dev/null @@ -1,143 +0,0 @@ ---- -title: Configure CI/CD for your Java application -linkTitle: Configure CI/CD -weight: 40 -keywords: java, CI/CD, local, development -description: Learn how to Configure CI/CD for your Java application -aliases: - - /language/java/configure-ci-cd/ - - /guides/language/java/configure-ci-cd/ ---- - -## Prerequisites - -Complete the previous sections of this guide, starting with [Containerize your app](containerize.md). You must have a [GitHub](https://github.com/signup) account and a verified [Docker](https://hub.docker.com/signup) account to complete this section. - -## Overview - -In this section, you'll learn how to set up and use GitHub Actions to build and push your Docker image to Docker Hub. You will complete the following steps: - -1. Create a new repository on GitHub. -2. Define the GitHub Actions workflow. -3. Run the workflow. - -## Step one: Create the repository - -Create a GitHub repository, configure the Docker Hub credentials, and push your source code. - -1. [Create a new repository](https://github.com/new) on GitHub. - -2. Open the repository **Settings**, and go to **Secrets and variables** > - **Actions**. - -3. Create a new **Repository variable** named `DOCKER_USERNAME` and your Docker ID as a value. - -4. Create a new [Personal Access Token (PAT)](/manuals/security/access-tokens.md#create-an-access-token) for Docker Hub. You can name this token `docker-tutorial`. Make sure access permissions include Read and Write. - -5. Add the PAT as a **Repository secret** in your GitHub repository, with the name - `DOCKERHUB_TOKEN`. - -6. In your local repository on your machine, run the following command to change - the origin to the repository you just created. Make sure you change - `your-username` to your GitHub username and `your-repository` to the name of - the repository you created. - - ```console - $ git remote set-url origin https://github.com/your-username/your-repository.git - ``` - -7. Run the following commands to stage, commit, and push your local repository to GitHub. - - ```console - $ git add -A - $ git commit -m "my commit" - $ git push -u origin main - ``` - -## Step two: Set up the workflow - -Set up your GitHub Actions workflow for building, testing, and pushing the image -to Docker Hub. - -1. Go to your repository on GitHub and then select the **Actions** tab. - The project already has the `maven-build` workflow to build and test your Java application with Maven. If you want, you can optionally disable this workflow because you won't use it in this guide. You'll create a new, alternate workflow to build, test, and push your image. - -2. Select **New workflow**. - -3. Select **set up a workflow yourself**. - - This takes you to a page for creating a new GitHub actions workflow file in - your repository, under `.github/workflows/main.yml` by default. - -4. In the editor window, copy and paste the following YAML configuration. - - ```yaml - name: ci - - on: - push: - branches: - - main - - jobs: - build: - runs-on: ubuntu-latest - steps: - - name: Login to Docker Hub - uses: docker/login-action@{{% param "login_action_version" %}} - with: - username: ${{ vars.DOCKER_USERNAME }} - password: ${{ secrets.DOCKERHUB_TOKEN }} - - - name: Set up Docker Buildx - uses: docker/setup-buildx-action@{{% param "setup_buildx_action_version" %}} - - - name: Build and test - uses: docker/build-push-action@{{% param "build_push_action_version" %}} - with: - target: test - load: true - - - name: Build and push - uses: docker/build-push-action@{{% param "build_push_action_version" %}} - with: - platforms: linux/amd64,linux/arm64 - push: true - target: final - tags: ${{ vars.DOCKER_USERNAME }}/${{ github.event.repository.name }}:latest - ``` - - For more information about the YAML syntax for `docker/build-push-action`, - refer to the [GitHub Action README](https://github.com/docker/build-push-action/blob/master/README.md). - -## Step three: Run the workflow - -Save the workflow file and run the job. - -1. Select **Commit changes...** and push the changes to the `main` branch. - - After pushing the commit, the workflow starts automatically. - -2. Go to the **Actions** tab. It displays the workflow. - - Selecting the workflow shows you the breakdown of all the steps. - -3. When the workflow is complete, go to your - [repositories on Docker Hub](https://hub.docker.com/repositories). - - If you see the new repository in that list, it means the GitHub Actions - successfully pushed the image to Docker Hub. - -## Summary - -In this section, you learned how to set up a GitHub Actions workflow for your application. - -Related information: - -- [Introduction to GitHub Actions](/guides/gha.md) -- [Docker Build GitHub Actions](/manuals/build/ci/github-actions/_index.md) -- [Workflow syntax for GitHub Actions](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions) - -## Next steps - -Next, learn how you can locally test and debug your workloads on Kubernetes before deploying. diff --git a/content/guides/java/deploy.md b/content/guides/java/deploy.md deleted file mode 100644 index 663fe4fd71ca..000000000000 --- a/content/guides/java/deploy.md +++ /dev/null @@ -1,155 +0,0 @@ ---- -title: Test your Java deployment -linkTitle: Test your deployment -weight: 50 -keywords: deploy, kubernetes, java -description: Learn how to develop locally using Kubernetes -aliases: - - /language/java/deploy/ - - /guides/language/java/deploy/ ---- - -## Prerequisites - -- Complete all the previous sections of this guide, starting with [Containerize your app](containerize.md). -- [Turn on Kubernetes](/manuals/desktop/use-desktop/kubernetes.md#enable-kubernetes) in Docker Desktop. - -## Overview - -In this section, you'll learn how to use Docker Desktop to deploy your -application to a fully-featured Kubernetes environment on your development -machine. This lets you test and debug your workloads on Kubernetes locally -before deploying. - -## Create a Kubernetes YAML file - -In your `spring-petclinic` directory, create a file named -`docker-java-kubernetes.yaml`. Open the file in an IDE or text editor and add -the following contents. Replace `DOCKER_USERNAME/REPO_NAME` with your Docker -username and the name of the repository that you created in [Configure CI/CD for -your Java application](configure-ci-cd.md). - -```yaml -apiVersion: apps/v1 -kind: Deployment -metadata: - name: docker-java-demo - namespace: default -spec: - replicas: 1 - selector: - matchLabels: - service: server - template: - metadata: - labels: - service: server - spec: - containers: - - name: server-service - image: DOCKER_USERNAME/REPO_NAME - imagePullPolicy: Always ---- -apiVersion: v1 -kind: Service -metadata: - name: service-entrypoint - namespace: default -spec: - type: NodePort - selector: - service: server - ports: - - port: 8080 - targetPort: 8080 - nodePort: 30001 -``` - -In this Kubernetes YAML file, there are two objects, separated by the `---`: - -- A Deployment, describing a scalable group of identical pods. In this case, - you'll get just one replica, or copy of your pod. That pod, which is - described under `template`, has just one container in it. The - container is created from the image built by GitHub Actions in [Configure CI/CD for - your Java application](configure-ci-cd.md). -- A NodePort service, which will route traffic from port 30001 on your host to - port 8080 inside the pods it routes to, allowing you to reach your app - from the network. - -To learn more about Kubernetes objects, see the [Kubernetes documentation](https://kubernetes.io/docs/home/). - -## Deploy and check your application - -1. In a terminal, navigate to `spring-petclinic` and deploy your application to - Kubernetes. - - ```console - $ kubectl apply -f docker-java-kubernetes.yaml - ``` - - You should see output that looks like the following, indicating your Kubernetes objects were created successfully. - - ```shell - deployment.apps/docker-java-demo created - service/service-entrypoint created - ``` - -2. Make sure everything worked by listing your deployments. - - ```console - $ kubectl get deployments - ``` - - Your deployment should be listed as follows: - - ```shell - NAME READY UP-TO-DATE AVAILABLE AGE - docker-java-demo 1/1 1 1 15s - ``` - - This indicates all one of the pods you asked for in your YAML are up and running. Do the same check for your services. - - ```console - $ kubectl get services - ``` - - You should get output like the following. - - ```shell - NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE - kubernetes ClusterIP 10.96.0.1 443/TCP 23h - service-entrypoint NodePort 10.99.128.230 8080:30001/TCP 75s - ``` - - In addition to the default `kubernetes` service, you can see your `service-entrypoint` service, accepting traffic on port 30001/TCP. - -3. In a terminal, curl the service. Note that a database wasn't deployed in - this example. - - ```console - $ curl --request GET \ - --url http://localhost:30001/actuator/health \ - --header 'content-type: application/json' - ``` - - You should get output like the following. - - ```console - {"status":"UP","groups":["liveness","readiness"]} - ``` - -4. Run the following command to tear down your application. - - ```console - $ kubectl delete -f docker-java-kubernetes.yaml - ``` - -## Summary - -In this section, you learned how to use Docker Desktop to deploy your application to a fully-featured Kubernetes environment on your development machine. - -Related information: - -- [Kubernetes documentation](https://kubernetes.io/docs/home/) -- [Deploy on Kubernetes with Docker Desktop](/manuals/desktop/use-desktop/kubernetes.md) -- [Swarm mode overview](/manuals/engine/swarm/_index.md) diff --git a/content/guides/java/run-tests.md b/content/guides/java/run-tests.md index c88025ad82b6..00624ed831ff 100644 --- a/content/guides/java/run-tests.md +++ b/content/guides/java/run-tests.md @@ -119,7 +119,3 @@ You should see output containing the following #15 DONE 101.4s ``` -## Next steps - -In the next section, you’ll take a look at how to set up a CI/CD pipeline using -GitHub Actions. diff --git a/content/guides/nextjs/_index.md b/content/guides/nextjs/_index.md index 995744c5c099..c75d3b806760 100644 --- a/content/guides/nextjs/_index.md +++ b/content/guides/nextjs/_index.md @@ -1,12 +1,11 @@ --- title: Containerize a Next.js application linkTitle: Next.js -description: Containerize, develop, test, and deploy Next.js apps with Docker and Kubernetes -keywords: getting started, Next.js, next.js, docker, language, Dockerfile, CI/CD, Kubernetes +description: Containerize, develop, and test Next.js apps with Docker +keywords: getting started, Next.js, next.js, docker, language, Dockerfile summary: | - This guide explains how to containerize Next.js applications, set up - development and testing in containers, automate builds with GitHub Actions, - and deploy to Kubernetes. + This guide explains how to containerize Next.js applications and set up + development and testing in containers. toc_min: 1 toc_max: 2 languages: [js] @@ -35,8 +34,6 @@ In this guide, you will learn how to: - Containerize and run a Next.js application using Docker. - Set up a local development environment for Next.js inside a container. - Run tests for your Next.js application within a Docker container. -- Configure a CI/CD pipeline using GitHub Actions for your containerized app. -- Deploy the containerized Next.js application to a local Kubernetes cluster for testing and debugging. To begin, you'll start by containerizing an existing Next.js application. diff --git a/content/guides/nextjs/configure-github-actions.md b/content/guides/nextjs/configure-github-actions.md deleted file mode 100644 index 2484e5a11b78..000000000000 --- a/content/guides/nextjs/configure-github-actions.md +++ /dev/null @@ -1,332 +0,0 @@ ---- -title: Automate your builds with GitHub Actions -linkTitle: GitHub Actions CI -weight: 60 -keywords: CI/CD, GitHub Actions, Next.js -description: Learn how to configure CI/CD using GitHub Actions for your Next.js application. - ---- - -## Prerequisites - -Complete all the previous sections of this guide, starting with [Containerize Next.js application](containerize.md). - -You must also have: -- A [GitHub](https://github.com/signup) account. -- A verified [Docker Hub](https://hub.docker.com/signup) account. - ---- - -## Overview - -In this section, you'll set up a CI/CD pipeline using [GitHub Actions](https://docs.github.com/en/actions) to automatically: - -- Build your Next.js application inside a Docker container. -- Run tests in a consistent environment. -- Push the production-ready image to [Docker Hub](https://hub.docker.com). - ---- - -## Integrate GitHub and Docker Hub - -To enable GitHub Actions to build and push Docker images, you'll securely -store your Docker Hub credentials in your new GitHub repository. - -### Step 1: Connect your GitHub repository to Docker Hub - -1. Create a Personal Access Token (PAT) from [Docker Hub](https://hub.docker.com) - 1. Go to your **Docker Hub account → Account Settings → Security**. - 2. Generate a new Access Token with **Read/Write** permissions. - 3. Name it something like `nextjs-sample`. - 4. Copy and save the token — you'll need it in Step 4. - -2. Create a repository in [Docker Hub](https://hub.docker.com/repositories/) - 1. Go to your **Docker Hub account → Create a repository**. - 2. For the Repository Name, use something descriptive — for example: `nextjs-sample`. - 3. Once created, copy and save the repository name — you'll need it in Step 4. - -3. Create a new [GitHub repository](https://github.com/new) for your Next.js project - -4. Add Docker Hub credentials as GitHub repository secrets - - In your newly created GitHub repository: - - 1. Navigate to: - **Settings → Secrets and variables → Actions → New repository secret**. - - 2. Add the following secrets: - - | Name | Value | - |-------------------|--------------------------------| - | `DOCKER_USERNAME` | Your Docker Hub username | - | `DOCKERHUB_TOKEN` | Your Docker Hub access token (created in Step 1) | - | `DOCKERHUB_PROJECT_NAME` | Your Docker Project Name (created in Step 2) | - - These secrets let GitHub Actions authenticate securely with Docker Hub - during automated workflows. - -5. Connect Your Local Project to GitHub - - Link your local project to the GitHub repository you just created by running the following command from your project root: - - ```console - $ git remote set-url origin https://github.com/{your-username}/{your-repository-name}.git - ``` - - >[!IMPORTANT] - >Replace `{your-username}` and `{your-repository}` with your actual GitHub username and repository name. - - To confirm that your local project is correctly connected to the remote GitHub repository, run: - - ```console - $ git remote -v - ``` - - You should see output similar to: - - ```console - origin https://github.com/{your-username}/{your-repository-name}.git (fetch) - origin https://github.com/{your-username}/{your-repository-name}.git (push) - ``` - - This confirms that your local repository is properly linked and ready to push your source code to GitHub. - -6. Push Your Source Code to GitHub - - Follow these steps to commit and push your local project to your GitHub repository: - - 1. Stage all files for commit. - - ```console - $ git add -A - ``` - This command stages all changes — including new, modified, and deleted files — preparing them for commit. - - - 2. Commit your changes. - - ```console - $ git commit -m "Initial commit" - ``` - This command creates a commit that snapshots the staged changes with a descriptive message. - - 3. Push the code to the `main` branch. - - ```console - $ git push -u origin main - ``` - This command pushes your local commits to the `main` branch of the remote GitHub repository and sets the upstream branch. - -Once completed, your code will be available on GitHub, and any GitHub Actions workflow you've configured will run automatically. - -> [!NOTE] -> Learn more about the Git commands used in this step: -> - [Git add](https://git-scm.com/docs/git-add) – Stage changes (new, modified, deleted) for commit -> - [Git commit](https://git-scm.com/docs/git-commit) – Save a snapshot of your staged changes -> - [Git push](https://git-scm.com/docs/git-push) – Upload local commits to your GitHub repository -> - [Git remote](https://git-scm.com/docs/git-remote) – View and manage remote repository URLs - ---- - -### Step 2: Set up the workflow - -Now you'll create a GitHub Actions workflow that builds your Docker image, runs tests, and pushes the image to Docker Hub. - -1. Go to your repository on GitHub and select the **Actions** tab in the top menu. - -2. Select **Set up a workflow yourself** when prompted. - - This opens an inline editor to create a new workflow file. By default, it will be saved to: - `.github/workflows/main.yml` - - -3. Add the following workflow configuration to the new file: - -```yaml -# CI/CD – Next.js Application with Docker -# Builds the app, runs tests in a container, and pushes the production image to Docker Hub. - -name: CI/CD – Next.js Application with Docker - -on: - push: - branches: [main] - pull_request: - branches: [main] - types: [opened, synchronize, reopened] - -jobs: - build-test-push: - name: Build, Test and Push Docker Image - runs-on: ubuntu-latest - - steps: - # 1. Checkout source code - - name: Checkout source code - uses: actions/checkout@v5 - with: - fetch-depth: 0 - - # 2. Set up Docker Buildx - - name: Set up Docker Buildx - uses: docker/setup-buildx-action@v4 - - # 3. Cache Docker layers - - name: Cache Docker layers - uses: actions/cache@v5 - with: - path: /tmp/.buildx-cache - key: ${{ runner.os }}-buildx-${{ github.sha }} - restore-keys: ${{ runner.os }}-buildx- - - # 4. Cache pnpm dependencies - - name: Cache pnpm dependencies - uses: actions/cache@v4 - with: - path: ~/.local/share/pnpm/store - key: ${{ runner.os }}-pnpm-${{ hashFiles('**/pnpm-lock.yaml') }} - restore-keys: ${{ runner.os }}-pnpm- - - # 5. Extract metadata - - name: Extract metadata - id: meta - run: | - echo "REPO_NAME=${GITHUB_REPOSITORY##*/}" >> "$GITHUB_OUTPUT" - echo "SHORT_SHA=${GITHUB_SHA::7}" >> "$GITHUB_OUTPUT" - - # 6. Build dev Docker image (for running tests) - - name: Build Docker image for tests - uses: docker/build-push-action@v6 - with: - context: . - file: Dockerfile.dev - tags: ${{ steps.meta.outputs.REPO_NAME }}-dev:latest - load: true - cache-from: type=local,src=/tmp/.buildx-cache - cache-to: type=local,dest=/tmp/.buildx-cache,mode=max - - # 7. Run Vitest tests inside the container - # Use same package-manager detection as Dockerfile (no corepack at runtime; node user can't write to /usr/local/bin) - - name: Run tests - run: | - docker run --rm \ - --workdir /app \ - --entrypoint "" \ - -e CI=true \ - ${{ steps.meta.outputs.REPO_NAME }}-dev:latest \ - sh -c "if [ -f package-lock.json ]; then npm run test:run; elif [ -f yarn.lock ]; then yarn test:run; elif [ -f pnpm-lock.yaml ]; then pnpm run test:run; else npm run test:run; fi" - env: - CI: true - NODE_ENV: test - timeout-minutes: 10 - - # 8. Log in to Docker Hub (only needed for push) - - name: Log in to Docker Hub - if: github.event_name == 'push' && github.ref == 'refs/heads/main' - uses: docker/login-action@v3 - with: - username: ${{ secrets.DOCKER_USERNAME }} - password: ${{ secrets.DOCKERHUB_TOKEN }} - - # 9. Build and push production image (only on push to main) - - name: Build and push production image - if: github.event_name == 'push' && github.ref == 'refs/heads/main' - uses: docker/build-push-action@v6 - with: - context: . - file: Dockerfile - push: true - platforms: linux/amd64,linux/arm64 - tags: | - ${{ secrets.DOCKER_USERNAME }}/${{ secrets.DOCKERHUB_PROJECT_NAME }}:latest - ${{ secrets.DOCKER_USERNAME }}/${{ secrets.DOCKERHUB_PROJECT_NAME }}:${{ steps.meta.outputs.SHORT_SHA }} - cache-from: type=local,src=/tmp/.buildx-cache - cache-to: type=local,dest=/tmp/.buildx-cache,mode=max - -``` - -This workflow performs the following tasks for your Next.js application: -- Triggers on every `push` or `pull request` targeting the `main` branch. -- Builds a development Docker image using `Dockerfile.dev`, optimized for testing. -- Executes unit tests using Jest inside a clean, containerized environment to ensure consistency. -- Halts the workflow immediately if any test fails — enforcing code quality. -- Caches both Docker build layers and npm dependencies for faster CI runs. -- Authenticates securely with Docker Hub using GitHub repository secrets. -- Builds a production-ready image using the `Dockerfile`. -- Tags and pushes the final image to Docker Hub with both `latest` and short SHA tags for traceability. - -> [!NOTE] -> For more information about `docker/build-push-action`, refer to the [GitHub Action README](https://github.com/docker/build-push-action/blob/master/README.md). - ---- - -### Step 3: Run the workflow - -After you've added your workflow file, it's time to trigger and observe the CI/CD process in action. - -1. Commit and push your workflow file - - Select "Commit changes…" in the GitHub editor. - - - This push will automatically trigger the GitHub Actions pipeline. - -2. Monitor the workflow execution - - 1. Go to the Actions tab in your GitHub repository. - 2. Select the workflow run to follow each step: `build`, `test`, and (if successful) `push`. - -3. Verify the Docker image on Docker Hub - - - After a successful workflow run, visit your [Docker Hub repositories](https://hub.docker.com/repositories). - - You should see a new image under your repository with: - - Repository name: `${your-repository-name}` - - Tags include: - - `latest` – represents the most recent successful build; ideal for quick testing or deployment. - - `` – a unique identifier based on the commit hash, useful for version tracking, rollbacks, and traceability. - -> [!TIP] Protect your main branch -> To maintain code quality and prevent accidental direct pushes, enable branch protection rules: -> - Navigate to your **GitHub repo → Settings → Branches**. -> - Under Branch protection rules, select **Add rule**. -> - Specify `main` as the branch name. -> - Enable options like: -> - *Require a pull request before merging*. -> - *Require status checks to pass before merging*. -> -> This ensures that only tested and reviewed code is merged into `main` branch. ---- - -## Summary - -In this section, you set up a complete CI/CD pipeline for your containerized Next.js application using GitHub Actions. - -Here's what you accomplished: - -- Created a new GitHub repository specifically for your project. -- Generated a secure Docker Hub access token and added it to GitHub as a secret. -- Defined a GitHub Actions workflow to: - - Build your application inside a Docker container. - - Run tests in a consistent, containerized environment. - - Push a production-ready image to Docker Hub if tests pass. -- Triggered and verified the workflow execution through GitHub Actions. -- Confirmed that your image was successfully published to Docker Hub. - -With this setup, your Next.js application is now ready for automated testing and deployment across environments — increasing confidence, consistency, and team productivity. - ---- - -## Related resources - -Deepen your understanding of automation and best practices for containerized apps: - -- [Introduction to GitHub Actions](/guides/gha.md) – Learn how GitHub Actions automate your workflows -- [Docker Build GitHub Actions](/manuals/build/ci/github-actions/_index.md) – Set up container builds with GitHub Actions -- [Workflow syntax for GitHub Actions](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions) – Full reference for writing GitHub workflows -- [Compose file reference](/compose/compose-file/) – Full configuration reference for `compose.yaml` -- [Best practices for writing Dockerfiles](/develop/develop-images/dockerfile_best-practices/) – Optimize your image for performance and security - ---- - -## Next steps - -Next, learn how you can locally test and debug your Next.js workloads on Kubernetes before deploying. This helps you ensure your application behaves as expected in a production-like environment, reducing surprises during deployment. diff --git a/content/guides/nextjs/deploy.md b/content/guides/nextjs/deploy.md deleted file mode 100644 index 7b1017e2c8bb..000000000000 --- a/content/guides/nextjs/deploy.md +++ /dev/null @@ -1,199 +0,0 @@ ---- -title: Test your Next.js deployment -linkTitle: Test your deployment -weight: 70 -keywords: deploy, kubernetes, next.js -description: Learn how to deploy locally to test and debug your Kubernetes deployment - ---- - -## Prerequisites - -Before you begin, make sure you've completed the following: -- Complete all the previous sections of this guide, starting with [Containerize Next.js application](containerize.md). -- [Enable Kubernetes](/manuals/desktop/use-desktop/kubernetes.md#enable-kubernetes) in Docker Desktop. - -> **New to Kubernetes?** -> Visit the [Kubernetes basics tutorial](https://kubernetes.io/docs/tutorials/kubernetes-basics/) to get familiar with how clusters, pods, deployments, and services work. - ---- - -## Overview - -This section guides you through deploying your containerized Next.js application locally using [Docker Desktop's built-in Kubernetes](/desktop/kubernetes/). Running your app in a local Kubernetes cluster allows you to closely simulate a real production environment, enabling you to test, validate, and debug your workloads with confidence before promoting them to staging or production. - ---- - -## Create a Kubernetes YAML file - -Follow these steps to define your deployment configuration: - -1. In the root of your project, create a new file named: nextjs-sample-kubernetes.yaml - -2. Open the file in your IDE or preferred text editor. - -3. Add the following configuration, and be sure to replace `{DOCKER_USERNAME}` and `{DOCKERHUB_PROJECT_NAME}` with your actual Docker Hub username and repository name from the previous [Automate your builds with GitHub Actions](configure-github-actions.md). - - -```yaml -apiVersion: apps/v1 -kind: Deployment -metadata: - name: nextjs-sample - namespace: default -spec: - replicas: 1 - selector: - matchLabels: - app: nextjs-sample - template: - metadata: - labels: - app: nextjs-sample - spec: - containers: - - name: nextjs-container - image: {DOCKER_USERNAME}/{DOCKERHUB_PROJECT_NAME}:latest - imagePullPolicy: Always - ports: - - containerPort: 3000 - env: - - name: NODE_ENV - value: "production" - - name: HOSTNAME - value: "0.0.0.0" ---- -apiVersion: v1 -kind: Service -metadata: - name: nextjs-sample-service - namespace: default -spec: - type: NodePort - selector: - app: nextjs-sample - ports: - - port: 3000 - targetPort: 3000 - nodePort: 30001 -``` - -This manifest defines two key Kubernetes resources, separated by `---`: - -- Deployment - Deploys a single replica of your Next.js application inside a pod. The pod uses the Docker image built and pushed by your GitHub Actions CI/CD workflow - (refer to [Automate your builds with GitHub Actions](configure-github-actions.md)). - The container listens on port `3000`, which is the default port for Next.js applications. - -- Service (NodePort) - Exposes the deployed pod to your local machine. - It forwards traffic from port `30001` on your host to port `3000` inside the container. - This lets you access the application in your browser at [http://localhost:30001](http://localhost:30001). - -> [!NOTE] -> To learn more about Kubernetes objects, see the [Kubernetes documentation](https://kubernetes.io/docs/home/). - ---- - -## Deploy and check your application - -Follow these steps to deploy your containerized Next.js app into a local Kubernetes cluster and verify that it's running correctly. - -### Step 1. Apply the Kubernetes configuration - -In your terminal, navigate to the directory where your `nextjs-sample-kubernetes.yaml` file is located, then deploy the resources using: - -```console - $ kubectl apply -f nextjs-sample-kubernetes.yaml -``` - -If everything is configured properly, you'll see confirmation that both the Deployment and the Service were created: - -```shell - deployment.apps/nextjs-sample created - service/nextjs-sample-service created -``` - -This output means that both the Deployment and the Service were successfully created and are now running inside your local cluster. - -### Step 2. Check the deployment status - -Run the following command to check the status of your deployment: - -```console - $ kubectl get deployments -``` - -You should see an output similar to: - -```shell - NAME READY UP-TO-DATE AVAILABLE AGE - nextjs-sample 1/1 1 1 14s -``` - -This confirms that your pod is up and running with one replica available. - -### Step 3. Verify the service exposure - -Check if the NodePort service is exposing your app to your local machine: - -```console -$ kubectl get services -``` - -You should see something like: - -```shell -NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE -nextjs-sample-service NodePort 10.100.244.65 3000:30001/TCP 1m -``` - -This output confirms that your app is available via NodePort on port 30001. - -### Step 4. Access your app in the browser - -Open your browser and navigate to [http://localhost:30001](http://localhost:30001). - -You should see your production-ready Next.js Sample application running — served by your local Kubernetes cluster. - -### Step 5. Clean up Kubernetes resources - -Once you're done testing, you can delete the deployment and service using: - -```console - $ kubectl delete -f nextjs-sample-kubernetes.yaml -``` - -Expected output: - -```shell - deployment.apps "nextjs-sample" deleted - service "nextjs-sample-service" deleted -``` - -This ensures your cluster stays clean and ready for the next deployment. - ---- - -## Summary - -In this section, you learned how to deploy your Next.js application to a local Kubernetes cluster using Docker Desktop. This setup allows you to test and debug your containerized app in a production-like environment before deploying it to the cloud. - -What you accomplished: - -- Created a Kubernetes Deployment and NodePort Service for your Next.js app -- Used `kubectl apply` to deploy the application locally -- Verified the app was running and accessible at `http://localhost:30001` -- Cleaned up your Kubernetes resources after testing - ---- - -## Related resources - -Explore official references and best practices to sharpen your Kubernetes deployment workflow: - -- [Kubernetes documentation](https://kubernetes.io/docs/home/) – Learn about core concepts, workloads, services, and more. -- [Deploy on Kubernetes with Docker Desktop](/manuals/desktop/use-desktop/kubernetes.md) – Use Docker Desktop's built-in Kubernetes support for local testing and development. -- [`kubectl` CLI reference](https://kubernetes.io/docs/reference/kubectl/) – Manage Kubernetes clusters from the command line. -- [Kubernetes Deployment resource](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/) – Understand how to manage and scale applications using Deployments. -- [Kubernetes Service resource](https://kubernetes.io/docs/concepts/services-networking/service/) – Learn how to expose your application to internal and external traffic. diff --git a/content/guides/nextjs/run-tests.md b/content/guides/nextjs/run-tests.md index 69e486e76d38..8f443f055bbc 100644 --- a/content/guides/nextjs/run-tests.md +++ b/content/guides/nextjs/run-tests.md @@ -262,6 +262,3 @@ Explore official references and best practices to sharpen your Docker testing wo - [Next.js Testing Documentation](https://nextjs.org/docs/app/building-your-application/testing) – Official Next.js testing guide. --- -## Next steps - -Next, you'll learn how to set up a CI/CD pipeline using GitHub Actions to automatically build and test your Next.js application in a containerized environment. This ensures your code is validated on every push or pull request, maintaining consistency and reliability across your development workflow. diff --git a/content/guides/nodejs/_index.md b/content/guides/nodejs/_index.md index bf73b585988b..af477e1d63c5 100644 --- a/content/guides/nodejs/_index.md +++ b/content/guides/nodejs/_index.md @@ -16,7 +16,7 @@ params: time: 20 minutes --- -[Node.js](https://nodejs.org/en) is a JavaScript runtime for building server-side applications. This guide shows you how to containerize a TypeScript Node.js application using Docker, starting from a simple Express API and progressively adding features like a database and CI/CD. +[Node.js](https://nodejs.org/en) is a JavaScript runtime for building server-side applications. This guide shows you how to containerize a TypeScript Node.js application using Docker, starting from a simple Express API and progressively adding features like a database. This guide focuses on a backend Node.js API. If you're building a standalone frontend application, Docker has dedicated guides for [React.js](/guides/reactjs/), [Vue.js](/guides/vuejs/), [Angular](/guides/angular/), and [Next.js](/guides/nextjs/). @@ -31,9 +31,6 @@ In this guide, you'll learn how to: - Containerize and run a Node.js application using Docker. - Set up a local development environment using containers. - Run tests inside a Docker container. -- Configure GitHub Actions for CI/CD with Docker. -- Inspect and generate supply chain attestations for your image. -- Deploy your containerized Node.js application to Kubernetes. Start by containerizing a Node.js application. diff --git a/content/guides/nodejs/configure-github-actions.md b/content/guides/nodejs/configure-github-actions.md deleted file mode 100644 index cd448ec88234..000000000000 --- a/content/guides/nodejs/configure-github-actions.md +++ /dev/null @@ -1,135 +0,0 @@ ---- -title: Automate your builds with GitHub Actions -linkTitle: GitHub Actions CI -weight: 40 -keywords: CI/CD, GitHub Actions, Node.js, Docker -description: Learn how to configure CI/CD using GitHub Actions for your Node.js application. -aliases: - - /language/nodejs/configure-ci-cd/ - - /guides/language/nodejs/configure-ci-cd/ ---- - -## Prerequisites - -Complete all the previous sections of this guide, starting with [Containerize a Node.js application](containerize.md). You must have a [GitHub](https://github.com/signup) account and a verified [Docker](https://hub.docker.com/signup) account to complete this section. - -If you haven't created a [GitHub repository](https://github.com/new) for your project yet, do that now. After creating the repository, [add a remote](https://docs.github.com/en/get-started/getting-started-with-git/managing-remote-repositories) and make sure you can commit and [push your code](https://docs.github.com/en/get-started/using-git/pushing-commits-to-a-remote-repository#about-git-push) to GitHub. - -1. In your project's GitHub repository, open **Settings**, and go to **Secrets and variables** > **Actions**. - -2. Under the **Variables** tab, create a new **Repository variable** named `DOCKER_USERNAME` with your Docker ID as the value. - -3. Create a new [Personal Access Token (PAT)](/manuals/security/access-tokens.md#create-an-access-token) for Docker Hub. You can name this token `docker-tutorial`. Make sure access permissions include Read and Write. - -4. Add the PAT as a **Repository secret** in your GitHub repository, with the name `DOCKERHUB_TOKEN`. - -## Overview - -GitHub Actions is a CI/CD automation tool built into GitHub. A workflow is a YAML file that tells GitHub which jobs to run when something happens in your repository, like a push to a branch or a pull request opening. Workflows live in the `.github/workflows/` directory of your repository. - -In this section, you'll add a workflow that runs your tests on every push to the main branch, then builds your Docker image and pushes it to Docker Hub. - -## Define the GitHub Actions workflow - -You can create a GitHub Actions workflow by creating a YAML file in the `.github/workflows/` directory of your repository. Use your favorite text editor or the GitHub web interface. - -If you prefer to use the GitHub web interface: - -1. Go to your repository on GitHub and select the **Actions** tab. - -2. Select **set up a workflow yourself**. - - This takes you to a page for creating a new GitHub Actions workflow file in your repository. By default, the file is created under `.github/workflows/main.yml`. Change the filename to `build.yml`. - -If you prefer to use your text editor, create a new file named `build.yml` in the `.github/workflows/` directory of your repository. - -Add the following content to the file: - -{{< files name="nodejs-docker-example" >}} - -{{< file path=".github/workflows/build.yml" status="new" >}} -```yaml -# GitHub Actions workflow that runs on every push to main. -# - test: runs Vitest unit tests inside a container. -# - build_and_push: signs in to Docker Hub and the DHI registry, then -# builds and pushes the image. -name: Build and push Docker image - -on: - push: - branches: - - main - -jobs: - test: - runs-on: ubuntu-latest - steps: - - uses: actions/checkout@{{% param "checkout_action_version" %}} - - - name: Run tests - run: docker build --target test -t nodejs-test . && docker run --rm nodejs-test - - build_and_push: - runs-on: ubuntu-latest - needs: test - steps: - - uses: actions/checkout@{{% param "checkout_action_version" %}} - - - name: Login to Docker Hub - uses: docker/login-action@{{% param "login_action_version" %}} - with: - username: ${{ vars.DOCKER_USERNAME }} - password: ${{ secrets.DOCKERHUB_TOKEN }} - - - name: Login to Docker Hardened Images - uses: docker/login-action@{{% param "login_action_version" %}} - with: - registry: dhi.io - username: ${{ vars.DOCKER_USERNAME }} - password: ${{ secrets.DOCKERHUB_TOKEN }} - - - name: Set up Docker Buildx - uses: docker/setup-buildx-action@{{% param "setup_buildx_action_version" %}} - - - name: Build and push - uses: docker/build-push-action@{{% param "build_push_action_version" %}} - with: - push: true - tags: ${{ vars.DOCKER_USERNAME }}/${{ github.event.repository.name }}:latest -``` -{{< /file >}} - -{{< /files >}} - -The workflow has two jobs: - -1. **test**: Builds the `test` stage of the Dockerfile and runs it. If tests fail, the workflow stops and `build_and_push` doesn't run. -2. **build_and_push**: Signs in to Docker Hub and the DHI registry, then builds and pushes the image. - -## Run the workflow - -Commit the changes and push them to the `main` branch. This workflow runs every time you push changes to `main`. You can find more information about workflow triggers in the [GitHub documentation](https://docs.github.com/en/actions/writing-workflows/choosing-when-your-workflow-runs/events-that-trigger-workflows). - -Go to the **Actions** tab of your GitHub repository. It displays the workflow. Selecting the workflow shows you the breakdown of all the steps. - -When the workflow is complete, go to your [repositories on Docker Hub](https://hub.docker.com/repositories). If you see the new repository in that list, the GitHub Actions workflow successfully pushed the image to Docker Hub. - -## Summary - -In this section, you learned how to set up a GitHub Actions workflow for your Node.js application that includes: - -- Running Vitest unit tests inside a container -- Building and pushing Docker images - -Related information: - -- [Introduction to GitHub Actions](/guides/gha.md) -- [Docker Build GitHub Actions](/manuals/build/ci/github-actions/_index.md) -- [docker/login-action](https://github.com/docker/login-action) -- [docker/build-push-action](https://github.com/docker/build-push-action) -- [Create a Docker Hub access token](/manuals/security/access-tokens.md#create-an-access-token) - -## Next steps - -In the next section, you'll learn how to inspect and generate supply chain -attestations for your image. See [Secure your supply chain](secure-supply-chain.md). diff --git a/content/guides/nodejs/deploy.md b/content/guides/nodejs/deploy.md deleted file mode 100644 index bbcdfeb1d429..000000000000 --- a/content/guides/nodejs/deploy.md +++ /dev/null @@ -1,274 +0,0 @@ ---- -title: Deploy your Node.js application -linkTitle: Deploy your app -weight: 50 -keywords: deploy, kubernetes, node, node.js, production -description: Learn how to deploy your containerized Node.js application to Kubernetes. -aliases: - - /language/nodejs/deploy/ - - /guides/language/nodejs/deploy/ ---- - -## Prerequisites - -- Complete all the previous sections of this guide, starting with [Containerize a Node.js application](containerize.md). -- [Turn on Kubernetes](/manuals/desktop/use-desktop/kubernetes.md#enable-kubernetes) in Docker Desktop. - -## Overview - -In this section, you'll deploy your containerized Node.js application to a local Kubernetes cluster using Docker Desktop. You'll create a Kubernetes manifest that describes how the application should run, including the application deployment, the PostgreSQL database, and the services that connect them. - -## Create a Kubernetes manifest - -Create a new file called `nodejs-docker-example-kubernetes.yaml` in your project root: - -{{< files name="nodejs-docker-example" >}} - -{{< file path="nodejs-docker-example-kubernetes.yaml" status="new" >}} -```yaml -apiVersion: v1 -kind: Namespace -metadata: - name: nodejs-docker-example - ---- -apiVersion: v1 -kind: ConfigMap -metadata: - name: app-config - namespace: nodejs-docker-example -data: - POSTGRES_SERVER: 'postgres' - POSTGRES_DB: 'example' - POSTGRES_USER: 'postgres' - ---- -apiVersion: v1 -kind: PersistentVolumeClaim -metadata: - name: postgres-pvc - namespace: nodejs-docker-example -spec: - accessModes: - - ReadWriteOnce - resources: - requests: - storage: 1Gi - ---- -apiVersion: apps/v1 -kind: Deployment -metadata: - name: postgres - namespace: nodejs-docker-example -spec: - replicas: 1 - selector: - matchLabels: - app: postgres - template: - metadata: - labels: - app: postgres - spec: - containers: - - name: postgres - image: dhi.io/postgres:18 - ports: - - containerPort: 5432 - env: - - name: POSTGRES_DB - valueFrom: - configMapKeyRef: - name: app-config - key: POSTGRES_DB - - name: POSTGRES_USER - valueFrom: - configMapKeyRef: - name: app-config - key: POSTGRES_USER - - name: POSTGRES_PASSWORD - valueFrom: - secretKeyRef: - name: app-secrets - key: db-password - volumeMounts: - - name: postgres-storage - mountPath: /var/lib/postgresql - readinessProbe: - exec: - command: [pg_isready] - initialDelaySeconds: 5 - periodSeconds: 5 - volumes: - - name: postgres-storage - persistentVolumeClaim: - claimName: postgres-pvc - ---- -apiVersion: v1 -kind: Service -metadata: - name: postgres - namespace: nodejs-docker-example -spec: - type: ClusterIP - ports: - - port: 5432 - targetPort: 5432 - selector: - app: postgres - ---- -apiVersion: apps/v1 -kind: Deployment -metadata: - name: server - namespace: nodejs-docker-example -spec: - replicas: 2 - selector: - matchLabels: - app: server - template: - metadata: - labels: - app: server - spec: - containers: - - name: server - image: DOCKER_USERNAME/nodejs-docker-example:latest - ports: - - containerPort: 3000 - env: - - name: POSTGRES_SERVER - valueFrom: - configMapKeyRef: - name: app-config - key: POSTGRES_SERVER - - name: POSTGRES_DB - valueFrom: - configMapKeyRef: - name: app-config - key: POSTGRES_DB - - name: POSTGRES_USER - valueFrom: - configMapKeyRef: - name: app-config - key: POSTGRES_USER - - name: POSTGRES_PASSWORD - valueFrom: - secretKeyRef: - name: app-secrets - key: db-password - readinessProbe: - httpGet: - path: /health - port: 3000 - initialDelaySeconds: 10 - periodSeconds: 5 - ---- -apiVersion: v1 -kind: Service -metadata: - name: server - namespace: nodejs-docker-example -spec: - type: ClusterIP - ports: - - port: 3000 - targetPort: 3000 - selector: - app: server -``` -{{< /file >}} - -{{< /files >}} - -Before applying the manifest, replace `DOCKER_USERNAME` in the `server` deployment's image field with your Docker Hub username. - -## Deploy to Kubernetes - -Apply the manifest to your local Kubernetes cluster: - -```console -$ kubectl apply -f nodejs-docker-example-kubernetes.yaml -``` - -You should see output confirming that the resources were created: - -```console -namespace/nodejs-docker-example created -configmap/app-config created -persistentvolumeclaim/postgres-pvc created -deployment.apps/postgres created -service/postgres created -deployment.apps/server created -service/server created -``` - -Then create the database secret from your password file: - -```console -$ kubectl create secret generic app-secrets \ - --namespace nodejs-docker-example \ - --from-file=db-password=db/password.txt -``` - -## Verify the deployment - -Check that your pods are running: - -```console -$ kubectl get pods -n nodejs-docker-example -``` - -Wait until all pods show `Running` in the STATUS column. Then verify your services: - -```console -$ kubectl get services -n nodejs-docker-example -``` - -## Access the application - -Use port forwarding to access the application from your local machine: - -```console -$ kubectl port-forward -n nodejs-docker-example service/server 3000:3000 -``` - -Open a new terminal and make a request to the application: - -```console -$ curl http://localhost:3000 -{"message":"Hello World"} -``` - -You can also create a hero: - -```console -$ curl -X POST http://localhost:3000/heroes/ \ - -H 'Content-Type: application/json' \ - -d '{"name": "my hero", "secret_name": "austing", "age": 12}' -``` - -## Clean up - -When you're done testing, remove the deployment: - -```console -$ kubectl delete -f nodejs-docker-example-kubernetes.yaml -``` - -## Summary - -In this section, you deployed your containerized Node.js application to Kubernetes. You created a manifest that defines the application and database deployments, applied it to a local cluster, and verified the application is accessible. - -Related information: - -- [Kubernetes documentation](https://kubernetes.io/docs/home/) -- [Deploy on Kubernetes with Docker Desktop](/manuals/desktop/use-desktop/kubernetes.md) -- [`kubectl` CLI reference](https://kubernetes.io/docs/reference/kubectl/) -- [Kubernetes Deployment resource](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/) -- [Kubernetes Service resource](https://kubernetes.io/docs/concepts/services-networking/service/) diff --git a/content/guides/nodejs/run-tests.md b/content/guides/nodejs/run-tests.md index f67879b426a0..9c84fa3dae0e 100644 --- a/content/guides/nodejs/run-tests.md +++ b/content/guides/nodejs/run-tests.md @@ -259,6 +259,3 @@ Related information: - [Compose file reference](/compose/compose-file/) - [`docker compose run` CLI reference](/reference/cli/docker/compose/run/) -## Next steps - -In the next section, you'll learn how to set up a CI/CD pipeline using GitHub Actions. diff --git a/content/guides/nodejs/secure-supply-chain.md b/content/guides/nodejs/secure-supply-chain.md deleted file mode 100644 index 504933bebb98..000000000000 --- a/content/guides/nodejs/secure-supply-chain.md +++ /dev/null @@ -1,141 +0,0 @@ ---- -title: Secure your Node.js image supply chain -linkTitle: Secure your supply chain -weight: 45 -keywords: node.js, node, sbom, provenance, attestations, docker scout, supply chain, security -description: Learn how to inspect, generate, and verify supply chain attestations for your Node.js container image. ---- - -## Prerequisites - -Complete [Automate your builds with GitHub Actions](configure-github-actions.md). - -## Overview - -When you ship a container image, what's inside it and where it came from -matters. Supply chain attestations are signed records that answer questions -like which packages are in the image, what vulnerabilities affect them, how -the image was built, and what security checks it passed. - -In this section, you'll inspect the attestations that ship with your Docker -Hardened Image base, generate your own SBOM and provenance attestations -during CI, and pin the base image by digest so your builds are reproducible. - -The inspection commands in this topic are shown manually so you can see what -each one returns. In a real workflow you'd automate these checks with -[Docker Scout](/scout/), which runs the same scans on every push, -enforces policies in CI, and surfaces results in your registry and pull -requests. - -## Inspect the base image attestations - -Docker Hardened Images are built to SLSA Build Level 3 and ship with a set of -signed attestations covering bill-of-materials, vulnerabilities, build -provenance, and security scans. See -[DHI attestations](/manuals/dhi/core-concepts/attestations.md) for the full -list of types and how to verify their signatures with Cosign. - -List all the attestations available on the Node.js DHI: - -```console -$ docker scout attest list registry://dhi.io/node:24-alpine3.23-dev -``` - -View the SBOM: - -```console -$ docker scout sbom registry://dhi.io/node:24-alpine3.23-dev -``` - -Check known vulnerabilities: - -```console -$ docker scout cves registry://dhi.io/node:24-alpine3.23-dev -``` - -> [!NOTE] -> -> The `registry://` prefix forces `docker scout` to fetch the image and its -> attestations from the registry instead of reading a locally pulled copy. If -> you've already pulled or built against the base image, the local copy -> doesn't have the attached attestations, so the prefix is required to see -> them. - -When you base your own image on a DHI image, these attestations stay attached to the base layer in the registry. Tools that inspect your image can follow the chain back to the DHI source. - -## Generate attestations for your image - -Update your GitHub Actions workflow to attach SBOM and provenance attestations to the image you push. - -Edit `.github/workflows/build.yml` and update the build-and-push step: - -```yaml {hl_lines="6-7"} -- name: Build and push Docker image - uses: docker/build-push-action@{{% param "build_push_action_version" %}} - with: - context: . - push: true - sbom: true - provenance: mode=max - tags: ${{ vars.DOCKER_USERNAME }}/${{ github.event.repository.name }}:latest -``` - -- `sbom: true` tells BuildKit to scan the built image and attach an SBOM attestation. -- `provenance: mode=max` records detailed build provenance, including the source repository, commit, and build parameters. - -The next time your workflow runs, the pushed image will carry these attestations alongside the image manifest in the registry. - -## Inspect your pushed image's attestations - -After your workflow pushes the image, inspect it the same way you inspected the base image: - -```console -$ docker scout attest list registry://DOCKER_USERNAME/REPO_NAME:latest -$ docker scout sbom registry://DOCKER_USERNAME/REPO_NAME:latest -``` - -The SBOM includes packages from every layer, including those inherited from `dhi.io/node:24-alpine3.23-dev`. The provenance record references the DHI base image by digest, so consumers of your image can trace the build chain back to the DHI source. - -## Pin the base image by digest - -Image tags like `dhi.io/node:24-alpine3.23-dev` move over time as new patches land. For reproducible builds, pin to an immutable digest. - -Look up the digest for each image: - -```console -$ docker buildx imagetools inspect dhi.io/node:24-alpine3.23-dev --format "{{ .Manifest.Digest }}" -sha256:2bf01111c7dfe429362f64b3977f0cd6e63ff39023012f88487dec7e83aa26ca -$ docker buildx imagetools inspect dhi.io/node:24-alpine3.23 --format "{{ .Manifest.Digest }}" -sha256:868827fd45c6a01f7f3337ba7ff3f48ebb14da10d8cf3d347f98ded5481317a5 -``` - -Each digest is a 64-character hex string. Update your `Dockerfile` to reference each digest on its corresponding `FROM` line: - -```dockerfile -FROM dhi.io/node:24-alpine3.23-dev@sha256:2bf01111c7dfe429362f64b3977f0cd6e63ff39023012f88487dec7e83aa26ca AS dev -# ... -FROM dhi.io/node:24-alpine3.23@sha256:868827fd45c6a01f7f3337ba7ff3f48ebb14da10d8cf3d347f98ded5481317a5 AS runner -``` - -> [!TIP] -> -> Pinning by digest also pins you to that image's vulnerabilities. Use [Dependabot](https://docs.github.com/en/code-security/dependabot) or [Renovate](https://docs.renovatebot.com/) to automate digest updates so you get a PR when a new patched image is available, with a changelog to review before merging. - -## Summary - -In this section, you learned how to: - -- Inspect the supply chain attestations that ship with the DHI base image, including SBOMs, CVE reports, and build provenance -- Generate SBOM and provenance attestations for your own image in CI -- Pin base images by digest for reproducible builds - -Related information: - -- [DHI attestations](/manuals/dhi/core-concepts/attestations.md) -- [Verify a Docker Hardened Image](/manuals/dhi/how-to/verify.md) -- [Docker Scout](/scout/) -- [Build attestations](/manuals/build/metadata/attestations/_index.md) - -## Next steps - -In the next section, you'll deploy your application to Kubernetes. diff --git a/content/guides/php/_index.md b/content/guides/php/_index.md index 358b13865aa9..1fe5f46142d8 100644 --- a/content/guides/php/_index.md +++ b/content/guides/php/_index.md @@ -20,8 +20,6 @@ The PHP language-specific guide teaches you how to create a containerized PHP ap - Containerize and run a PHP application - Set up a local environment to develop a PHP application using containers - Run tests for a PHP application within containers -- Configure a CI/CD pipeline for a containerized PHP application using GitHub Actions -- Deploy your containerized application locally to Kubernetes to test and debug your deployment After completing the PHP language-specific guide, you should be able to containerize your own PHP application based on the examples and instructions provided in this guide. diff --git a/content/guides/php/configure-ci-cd.md b/content/guides/php/configure-ci-cd.md deleted file mode 100644 index 3f1053e5b870..000000000000 --- a/content/guides/php/configure-ci-cd.md +++ /dev/null @@ -1,148 +0,0 @@ ---- -title: Configure CI/CD for your PHP application -linkTitle: Configure CI/CD -weight: 40 -keywords: php, CI/CD -description: Learn how to Configure CI/CD for your PHP application -aliases: - - /language/php/configure-ci-cd/ - - /guides/language/php/configure-ci-cd/ ---- - -## Prerequisites - -Complete all the previous sections of this guide, starting with [Containerize a PHP application](containerize.md). You must have a [GitHub](https://github.com/signup) account and a verified [Docker](https://hub.docker.com/signup) account to complete this section. - -## Overview - -In this section, you'll learn how to set up and use GitHub Actions to build and test your Docker image as well as push it to Docker Hub. You will complete the following steps: - -1. Create a new repository on GitHub. -2. Define the GitHub Actions workflow. -3. Run the workflow. - -## Step one: Create the repository - -Create a GitHub repository, configure the Docker Hub credentials, and push your source code. - -1. [Create a new repository](https://github.com/new) on GitHub. - -2. Open the repository **Settings**, and go to **Secrets and variables** > - **Actions**. - -3. Create a new **Repository variable** named `DOCKER_USERNAME` and your Docker ID as a value. - -4. Create a new [Personal Access Token (PAT)](/manuals/security/access-tokens.md#create-an-access-token) for Docker Hub. You can name this token `docker-tutorial`. Make sure access permissions include Read and Write. - -5. Add the PAT as a **Repository secret** in your GitHub repository, with the name - `DOCKERHUB_TOKEN`. - -6. In your local repository on your machine, run the following command to change - the origin to the repository you just created. Make sure you change - `your-username` to your GitHub username and `your-repository` to the name of - the repository you created. - - ```console - $ git remote set-url origin https://github.com/your-username/your-repository.git - ``` - -7. In your local repository on your machine, run the following command to rename - the branch to main. - - ```console - $ git branch -M main - ``` - -8. Run the following commands to stage, commit, and then push your local - repository to GitHub. - - ```console - $ git add -A - $ git commit -m "my first commit" - $ git push -u origin main - ``` - -## Step two: Set up the workflow - -Set up your GitHub Actions workflow for building, testing, and pushing the image -to Docker Hub. - -1. Go to your repository on GitHub and then select the **Actions** tab. - -2. Select **set up a workflow yourself**. - - This takes you to a page for creating a new GitHub actions workflow file in - your repository, under `.github/workflows/main.yml` by default. - -3. In the editor window, copy and paste the following YAML configuration. - - ```yaml - name: ci - - on: - push: - branches: - - main - - jobs: - build: - runs-on: ubuntu-latest - steps: - - name: Login to Docker Hub - uses: docker/login-action@{{% param "login_action_version" %}} - with: - username: ${{ vars.DOCKER_USERNAME }} - password: ${{ secrets.DOCKERHUB_TOKEN }} - - - name: Set up Docker Buildx - uses: docker/setup-buildx-action@{{% param "setup_buildx_action_version" %}} - - - name: Build and test - uses: docker/build-push-action@{{% param "build_push_action_version" %}} - with: - target: test - load: true - - - name: Build and push - uses: docker/build-push-action@{{% param "build_push_action_version" %}} - with: - platforms: linux/amd64,linux/arm64 - push: true - target: final - tags: ${{ vars.DOCKER_USERNAME }}/${{ github.event.repository.name }}:latest - ``` - - For more information about the YAML syntax for `docker/build-push-action`, - refer to the [GitHub Action README](https://github.com/docker/build-push-action/blob/master/README.md). - -## Step three: Run the workflow - -Save the workflow file and run the job. - -1. Select **Commit changes...** and push the changes to the `main` branch. - - After pushing the commit, the workflow starts automatically. - -2. Go to the **Actions** tab. It displays the workflow. - - Selecting the workflow shows you the breakdown of all the steps. - -3. When the workflow is complete, go to your - [repositories on Docker Hub](https://hub.docker.com/repositories). - - If you see the new repository in that list, it means the GitHub Actions - successfully pushed the image to Docker Hub. - -## Summary - -In this section, you learned how to set up a GitHub Actions workflow for your application. - -Related information: - -- [Introduction to GitHub Actions](/guides/gha.md) -- [Docker Build GitHub Actions](/manuals/build/ci/github-actions/_index.md) -- [Workflow syntax for GitHub Actions](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions) - -## Next steps - -Next, learn how you can locally test and debug your workloads on Kubernetes before deploying. diff --git a/content/guides/php/deploy.md b/content/guides/php/deploy.md deleted file mode 100644 index bd45d5ec0171..000000000000 --- a/content/guides/php/deploy.md +++ /dev/null @@ -1,146 +0,0 @@ ---- -title: Test your PHP deployment -linkTitle: Test your deployment -weight: 50 -keywords: deploy, php, local, development -description: Learn how to deploy your application -aliases: - - /language/php/deploy/ - - /guides/language/php/deploy/ ---- - -## Prerequisites - -- Complete all the previous sections of this guide, starting with [Containerize - a PHP application](containerize.md). -- [Turn on Kubernetes](/manuals/desktop/use-desktop/kubernetes.md#enable-kubernetes) in Docker - Desktop. - -## Overview - -In this section, you'll learn how to use Docker Desktop to deploy your -application to a fully-featured Kubernetes environment on your development -machine. This allows you to test and debug your workloads on Kubernetes locally -before deploying. - -## Create a Kubernetes YAML file - -In your `docker-php-sample` directory, create a file named -`docker-php-kubernetes.yaml`. Open the file in an IDE or text editor and add -the following contents. Replace `DOCKER_USERNAME/REPO_NAME` with your Docker -username and the name of the repository that you created in [Configure CI/CD for -your PHP application](configure-ci-cd.md). - -```yaml -apiVersion: apps/v1 -kind: Deployment -metadata: - name: docker-php-demo - namespace: default -spec: - replicas: 1 - selector: - matchLabels: - hello-php: web - template: - metadata: - labels: - hello-php: web - spec: - containers: - - name: hello-site - image: DOCKER_USERNAME/REPO_NAME - imagePullPolicy: Always ---- -apiVersion: v1 -kind: Service -metadata: - name: php-entrypoint - namespace: default -spec: - type: NodePort - selector: - hello-php: web - ports: - - port: 80 - targetPort: 80 - nodePort: 30001 -``` - -In this Kubernetes YAML file, there are two objects, separated by the `---`: - -- A Deployment, describing a scalable group of identical pods. In this case, - you'll get just one replica, or copy of your pod. That pod, which is - described under `template`, has just one container in it. The container is - created from the image built by GitHub Actions in [Configure CI/CD for your - PHP application](configure-ci-cd.md). -- A NodePort service, which will route traffic from port 30001 on your host to - port 80 inside the pods it routes to, allowing you to reach your app - from the network. - -To learn more about Kubernetes objects, see the [Kubernetes documentation](https://kubernetes.io/docs/home/). - -## Deploy and check your application - -1. In a terminal, navigate to the `docker-php-sample` directory - and deploy your application to Kubernetes. - - ```console - $ kubectl apply -f docker-php-kubernetes.yaml - ``` - - You should see output that looks like the following, indicating your Kubernetes objects were created successfully. - - ```text - deployment.apps/docker-php-demo created - service/php-entrypoint created - ``` - -2. Make sure everything worked by listing your deployments. - - ```console - $ kubectl get deployments - ``` - - Your deployment should be listed as follows: - - ```text - NAME READY UP-TO-DATE AVAILABLE AGE - docker-php-demo 1/1 1 1 6s - ``` - - This indicates all of the pods are up and running. Do the same check for your services. - - ```console - $ kubectl get services - ``` - - You should get output like the following. - - ```text - NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE - kubernetes ClusterIP 10.96.0.1 443/TCP 7d22h - php-entrypoint NodePort 10.111.101.229 80:30001/TCP 33s - ``` - - In addition to the default `kubernetes` service, you can see your `php-entrypoint` service. The `php-entrypoint` service is accepting traffic on port 30001/TCP. - -3. Open a browser and visit your app at - [http://localhost:30001/hello.php](http://localhost:30001/hello.php). You - should see your application. - -4. Run the following command to tear down your application. - - ```console - $ kubectl delete -f docker-php-kubernetes.yaml - ``` - -## Summary - -In this section, you learned how to use Docker Desktop to deploy your application to a fully-featured Kubernetes environment on your development machine. - -Related information: - -- [Kubernetes documentation](https://kubernetes.io/docs/home/) -- [Deploy on Kubernetes with Docker Desktop](/manuals/desktop/use-desktop/kubernetes.md) -- [Swarm mode overview](/manuals/engine/swarm/_index.md) diff --git a/content/guides/php/run-tests.md b/content/guides/php/run-tests.md index 7ddad4d72fb8..feb44a8f96fa 100644 --- a/content/guides/php/run-tests.md +++ b/content/guides/php/run-tests.md @@ -113,6 +113,3 @@ Related information: - [docker compose run](/reference/cli/docker/compose/run/) -## Next steps - -Next, you’ll learn how to set up a CI/CD pipeline using GitHub Actions. diff --git a/content/guides/python/_index.md b/content/guides/python/_index.md index 7e4c1dbfa5ad..2afeabfbf0ff 100644 --- a/content/guides/python/_index.md +++ b/content/guides/python/_index.md @@ -27,7 +27,5 @@ The Python language-specific guide teaches you how to containerize a Python appl - Containerize and run a Python application - Set up a local environment to develop a Python application using containers - Lint, format, typing and best practices -- Configure a CI/CD pipeline for a containerized Python application using GitHub Actions -- Deploy your containerized Python application locally to Kubernetes to test and debug your deployment Start by containerizing an existing Python application. diff --git a/content/guides/python/configure-github-actions.md b/content/guides/python/configure-github-actions.md deleted file mode 100644 index e935147bec1a..000000000000 --- a/content/guides/python/configure-github-actions.md +++ /dev/null @@ -1,161 +0,0 @@ ---- -title: Automate your builds with GitHub Actions -linkTitle: GitHub Actions CI -weight: 40 -keywords: ci/cd, github actions, python, flask -description: Learn how to configure CI/CD using GitHub Actions for your Python application. -aliases: - - /language/python/configure-ci-cd/ - - /guides/language/python/configure-ci-cd/ - - /guides/python/configure-ci-cd/ ---- - -## Prerequisites - -Complete all the previous sections of this guide, starting with [Containerize a Python application](containerize.md). You must have a [GitHub](https://github.com/signup) account and a verified [Docker](https://hub.docker.com/signup) account to complete this section. - -If you didn't create a [GitHub repository](https://github.com/new) for your project yet, it is time to do it. After creating the repository, don't forget to [add a remote](https://docs.github.com/en/get-started/getting-started-with-git/managing-remote-repositories) and ensure you can commit and [push your code](https://docs.github.com/en/get-started/using-git/pushing-commits-to-a-remote-repository#about-git-push) to GitHub. - -1. In your project's GitHub repository, open **Settings**, and go to **Secrets and variables** > **Actions**. - -2. Under the **Variables** tab, create a new **Repository variable** named `DOCKER_USERNAME` and your Docker ID as a value. - -3. Create a new [Personal Access Token (PAT)](/manuals/security/access-tokens.md#create-an-access-token) for Docker Hub. You can name this token `docker-tutorial`. Make sure access permissions include Read and Write. - -4. Add the PAT as a **Repository secret** in your GitHub repository, with the name - `DOCKERHUB_TOKEN`. - -## Overview - -GitHub Actions is a CI/CD automation tool built into GitHub. A workflow is a -YAML file that tells GitHub which jobs to run when something happens in your -repository, like a push to a branch or a pull request opening. Workflows live -in the `.github/workflows/` directory of your repository. - -In this section, you'll add a workflow that runs your linting, formatting, and -type checks on every push to the main branch, then builds your Docker image -and pushes it to Docker Hub. - -## 1. Define the GitHub Actions workflow - -You can create a GitHub Actions workflow by creating a YAML file in the `.github/workflows/` directory of your repository. To do this use your favorite text editor or the GitHub web interface. The following steps show you how to create a workflow file using the GitHub web interface. - -If you prefer to use the GitHub web interface, follow these steps: - -1. Go to your repository on GitHub and then select the **Actions** tab. - -2. Select **set up a workflow yourself**. - - This takes you to a page for creating a new GitHub Actions workflow file in - your repository. By default, the file is created under `.github/workflows/main.yml`. Change the file name to `build.yml`. - -If you prefer to use your text editor, create a new file named `build.yml` in the `.github/workflows/` directory of your repository. - -Add the following content to the file: - -{{< files name="python-docker-example" >}} - -{{< file path=".github/workflows/build.yml" status="new" >}} -```yaml -# GitHub Actions workflow that runs on every push to main. -# - lint-test: runs pre-commit hooks (Ruff) and Pyright type checks. -# - build_and_push: signs in to Docker Hub and the DHI registry, then -# builds and pushes the image (with SBOM and provenance attestations). -name: Build and push Docker image - -on: - push: - branches: - - main - -jobs: - lint-test: - runs-on: ubuntu-latest - steps: - - uses: actions/checkout@{{% param "checkout_action_version" %}} - - - name: Set up Python - uses: actions/setup-python@v6 - with: - python-version: '3.12' - - - name: Install dependencies - run: | - python -m pip install --upgrade pip - pip install -r requirements.txt - pip install pre-commit pyright - - - name: Run pre-commit hooks - run: pre-commit run --all-files - - - name: Run pyright - run: pyright - - build_and_push: - runs-on: ubuntu-latest - steps: - - uses: actions/checkout@{{% param "checkout_action_version" %}} - - - name: Login to Docker Hub - uses: docker/login-action@{{% param "login_action_version" %}} - with: - username: ${{ vars.DOCKER_USERNAME }} - password: ${{ secrets.DOCKERHUB_TOKEN }} - - - name: Login to Docker Hardened Images - uses: docker/login-action@{{% param "login_action_version" %}} - with: - registry: dhi.io - username: ${{ vars.DOCKER_USERNAME }} - password: ${{ secrets.DOCKERHUB_TOKEN }} - - - name: Set up Docker Buildx - uses: docker/setup-buildx-action@{{% param "setup_buildx_action_version" %}} - - - name: Build and push - uses: docker/build-push-action@{{% param "build_push_action_version" %}} - with: - push: true - tags: ${{ vars.DOCKER_USERNAME }}/${{ github.event.repository.name }}:latest -``` -{{< /file >}} - -{{< /files >}} - -Each GitHub Actions workflow includes one or several jobs. Each job consists of steps. Each step can either run a set of commands or use already [existing actions](https://github.com/marketplace?type=actions). The action above has three steps: - -1. [Login to Docker Hub](https://github.com/docker/login-action): Action logs in to Docker Hub using the Docker ID and Personal Access Token (PAT) you created earlier. - -2. [Set up Docker Buildx](https://github.com/docker/setup-buildx-action): Action sets up Docker [Buildx](https://github.com/docker/buildx), a CLI plugin that extends the capabilities of the Docker CLI. - -3. [Build and push](https://github.com/docker/build-push-action): Action builds and pushes the Docker image to Docker Hub. The `tags` parameter specifies the image name and tag. The `latest` tag is used in this example. - -## 2. Run the workflow - -Commit the changes and push them to the `main` branch. This workflow is runs every time you push changes to the `main` branch. You can find more information about workflow triggers [in the GitHub documentation](https://docs.github.com/en/actions/writing-workflows/choosing-when-your-workflow-runs/events-that-trigger-workflows). - -Go to the **Actions** tab of you GitHub repository. It displays the workflow. Selecting the workflow shows you the breakdown of all the steps. - -When the workflow is complete, go to your [repositories on Docker Hub](https://hub.docker.com/repositories). If you see the new repository in that list, it means the GitHub Actions workflow successfully pushed the image to Docker Hub. - -## Summary - -In this section, you learned how to set up a GitHub Actions workflow for your Python application that includes: - -- Running pre-commit hooks for linting and formatting -- Static type checking with Pyright -- Building and pushing Docker images - -Related information: - -- [Introduction to GitHub Actions](/guides/gha.md) -- [Docker Build GitHub Actions](/manuals/build/ci/github-actions/_index.md) -- [docker/login-action](https://github.com/docker/login-action) -- [docker/build-push-action](https://github.com/docker/build-push-action) -- [Create a Docker Hub access token](/manuals/security/access-tokens.md#create-an-access-token) - -## Next steps - -In the next section, you'll learn how to inspect and generate supply chain -attestations for your image. See [Secure your supply chain](secure-supply-chain.md). - diff --git a/content/guides/python/deploy.md b/content/guides/python/deploy.md deleted file mode 100644 index a47ef1213127..000000000000 --- a/content/guides/python/deploy.md +++ /dev/null @@ -1,341 +0,0 @@ ---- -title: Test your Python deployment -linkTitle: Test your deployment -weight: 50 -keywords: deploy, kubernetes, python -description: Learn how to develop locally using Kubernetes -aliases: - - /language/python/deploy/ - - /guides/language/python/deploy/ ---- - -## Prerequisites - -- Complete all the previous sections of this guide, starting with [Use containers for Python development](develop.md). -- [Turn on Kubernetes](/manuals/desktop/use-desktop/kubernetes.md#enable-kubernetes) in Docker Desktop. - -## Overview - -[Kubernetes](https://kubernetes.io/) is an open source platform that runs and -orchestrates container workloads across one or more machines. You describe -what you want to run, like which container images, how many replicas, and -which network ports to expose, in YAML manifest files. Kubernetes reads the -manifests and makes the cluster match that description. - -In this section, you'll use the Kubernetes environment built into Docker -Desktop to deploy your application locally. You'll write two manifest files, -one for the PostgreSQL database and one for the FastAPI application, apply -them with `kubectl`, and verify the deployment by hitting your application -from a terminal. - -## Registry authentication - -The Docker Hardened Images used in this guide are hosted on `dhi.io`. Docker -Desktop's Kubernetes shares credentials with Docker Desktop, so the `docker login dhi.io` -you completed earlier is all that's needed. No additional image pull secret is required. - -> [!NOTE] -> -> If you're deploying to a Kubernetes cluster outside of Docker Desktop, you'll -> need to create an image pull secret and reference it in your pod specs. See -> [Use a Docker Hardened Image](/dhi/how-to/use/#use-with-kubernetes) for instructions. - -## Create a Kubernetes YAML file - -Create the following two Kubernetes manifest files in your -`python-docker-example` directory. Before applying -`docker-python-kubernetes.yaml`, replace `DOCKER_USERNAME/REPO_NAME` with your -Docker username and the repository name that you created in [Configure CI/CD for -your Python application](./configure-github-actions.md). - -{{< files name="python-docker-example" >}} - -{{< file path="docker-postgres-kubernetes.yaml" status="new" >}} -```yaml -# Kubernetes manifests for the PostgreSQL database used by the FastAPI app. -# Contains a Deployment, Service, PersistentVolumeClaim, and Secret. - -# Deployment: runs one PostgreSQL pod. The image, port, env vars, and the -# persistent volume mount are all defined here. -apiVersion: apps/v1 -kind: Deployment -metadata: - name: postgres - namespace: default -spec: - replicas: 1 - selector: - matchLabels: - app: postgres - template: - metadata: - labels: - app: postgres - spec: - containers: - - name: postgres - image: dhi.io/postgres:18 - ports: - - containerPort: 5432 - env: - - name: POSTGRES_DB - value: example - - name: POSTGRES_USER - value: postgres - - name: POSTGRES_PASSWORD - valueFrom: - secretKeyRef: - name: postgres-secret - key: POSTGRES_PASSWORD - volumeMounts: - - name: postgres-data - mountPath: /var/lib/postgresql - volumes: - - name: postgres-data - persistentVolumeClaim: - claimName: postgres-pvc ---- -# Service: exposes PostgreSQL inside the cluster on port 5432 so the -# application pod can reach it by the DNS name `postgres`. -apiVersion: v1 -kind: Service -metadata: - name: postgres - namespace: default -spec: - ports: - - port: 5432 - selector: - app: postgres ---- -# PersistentVolumeClaim: storage that survives pod restarts. -apiVersion: v1 -kind: PersistentVolumeClaim -metadata: - name: postgres-pvc - namespace: default -spec: - accessModes: - - ReadWriteOnce - resources: - requests: - storage: 1Gi ---- -# Secret: holds the database password (base64-encoded). Referenced by both -# the postgres Deployment and the application Deployment. -apiVersion: v1 -kind: Secret -metadata: - name: postgres-secret - namespace: default -type: Opaque -data: - POSTGRES_PASSWORD: cG9zdGdyZXNfcGFzc3dvcmQ= # Base64 encoded password (e.g., 'postgres_password') -``` -{{< /file >}} - -{{< file path="docker-python-kubernetes.yaml" status="new" >}} -```yaml -# Kubernetes manifests for the FastAPI application. -# Contains a Deployment and a NodePort Service. - -# Deployment: runs the FastAPI app. Connection details to the postgres -# service are passed in via environment variables, and the database -# password comes from the shared postgres-secret. -apiVersion: apps/v1 -kind: Deployment -metadata: - name: docker-python-demo - namespace: default -spec: - replicas: 1 - selector: - matchLabels: - service: fastapi - template: - metadata: - labels: - service: fastapi - spec: - containers: - - name: fastapi-service - image: DOCKER_USERNAME/REPO_NAME - imagePullPolicy: Always - env: - - name: POSTGRES_PASSWORD - valueFrom: - secretKeyRef: - name: postgres-secret - key: POSTGRES_PASSWORD - - name: POSTGRES_USER - value: postgres - - name: POSTGRES_DB - value: example - - name: POSTGRES_SERVER - value: postgres - - name: POSTGRES_PORT - value: "5432" - ports: - - containerPort: 8000 ---- -# Service: exposes the FastAPI app on port 30001 of the cluster node so -# you can reach it from your host with `curl http://localhost:30001/`. -apiVersion: v1 -kind: Service -metadata: - name: service-entrypoint - namespace: default -spec: - type: NodePort - selector: - service: fastapi - ports: - - port: 8000 - targetPort: 8000 - nodePort: 30001 -``` -{{< /file >}} - -{{< /files >}} - -In these Kubernetes YAML files, there are various objects, separated by the `---`: - -- A Deployment, describing a scalable group of identical pods. In this case, - you'll get just one replica, or copy of your pod. That pod, which is - described under `template`, has just one container in it. The - container is created from the image built by GitHub Actions in [Configure CI/CD for - your Python application](configure-github-actions.md). -- A Service, which will define how the ports are mapped in the containers. -- A PersistentVolumeClaim, to define a storage that will be persistent through restarts for the database. -- A Secret, which stores the database password as a Kubernetes Secret resource. -- A NodePort service, which will route traffic from port 30001 on your host to - port 8000 inside the pods it routes to, so you can reach your app - from the network. - -To learn more about Kubernetes objects, see the [Kubernetes documentation](https://kubernetes.io/docs/home/). - -> [!NOTE] -> -> The `NodePort` service is good for development and testing. For production, implement an [ingress controller](https://kubernetes.io/docs/concepts/services-networking/ingress-controllers/) instead. - -## Deploy and check your application - -1. In a terminal, navigate to `python-docker-example` and deploy your database to - Kubernetes. - - ```console - $ kubectl apply -f docker-postgres-kubernetes.yaml - ``` - - You should see output that looks like the following, indicating your Kubernetes objects were created successfully. - - ```console - deployment.apps/postgres created - service/postgres created - persistentvolumeclaim/postgres-pvc created - secret/postgres-secret created - ``` - - Now, deploy your Python application. - - ```console - $ kubectl apply -f docker-python-kubernetes.yaml - ``` - - You should see output that looks like the following, indicating your Kubernetes objects were created successfully. - - ```console - deployment.apps/docker-python-demo created - service/service-entrypoint created - ``` - -2. Make sure everything worked by listing your deployments. - - ```console - $ kubectl get deployments - ``` - - Your deployment should be listed as follows: - - ```console - NAME READY UP-TO-DATE AVAILABLE AGE - docker-python-demo 1/1 1 1 48s - postgres 1/1 1 1 2m39s - ``` - - This indicates all one of the pods you asked for in your YAML are up and running. Do the same check for your services. - - ```console - $ kubectl get services - ``` - - You should get output like the following. - - ```console - NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE - kubernetes ClusterIP 10.43.0.1 443/TCP 13h - postgres ClusterIP 10.43.209.25 5432/TCP 3m10s - service-entrypoint NodePort 10.43.67.120 8000:30001/TCP 79s - ``` - - In addition to the default `kubernetes` service, you can see your `service-entrypoint` service, accepting traffic on port 30001/TCP and the internal `ClusterIP` `postgres` with the port `5432` open to accept connections from your Python app. - -3. In a terminal, curl the root endpoint to verify the application is running. - - ```console - $ curl http://localhost:30001/ - Hello, Docker! - ``` - -4. Exercise the database by creating a hero with a POST request: - - ```console - $ curl -X 'POST' \ - 'http://localhost:30001/heroes/' \ - -H 'accept: application/json' \ - -H 'Content-Type: application/json' \ - -d '{ - "id": 1, - "name": "my hero", - "secret_name": "austing", - "age": 12 - }' - ``` - - You should receive the following response: - - ```json - { - "age": 12, - "id": 1, - "name": "my hero", - "secret_name": "austing" - } - ``` - - Then read it back with a GET request: - - ```console - $ curl http://localhost:30001/heroes/ - ``` - - You should receive an array containing the hero you just created. This - confirms the application can read from and write to the PostgreSQL database - running in the cluster. - -5. Run the following commands to tear down your application. - - ```console - $ kubectl delete -f docker-python-kubernetes.yaml - $ kubectl delete -f docker-postgres-kubernetes.yaml - ``` - -## Summary - -In this section, you learned how to use Docker Desktop to deploy your application to a fully-featured Kubernetes environment on your development machine. - -Related information: - -- [Kubernetes documentation](https://kubernetes.io/docs/home/) -- [Deploy on Kubernetes with Docker Desktop](/manuals/desktop/use-desktop/kubernetes.md) -- [Use a Docker Hardened Image with Kubernetes](/dhi/how-to/use/#use-with-kubernetes) diff --git a/content/guides/python/lint-format-typing.md b/content/guides/python/lint-format-typing.md index 64e5b3c5b080..607fb6d9dc38 100644 --- a/content/guides/python/lint-format-typing.md +++ b/content/guides/python/lint-format-typing.md @@ -12,8 +12,7 @@ aliases: Complete [Develop your app](develop.md). This topic requires a local Python installation because the tools and Git hooks introduced here run on your -host. If you don't want to install Python locally, skip this topic. The same -checks run in CI in the [next topic](configure-github-actions.md). +host. If you don't want to install Python locally, you can skip this topic. ## Overview @@ -191,6 +190,5 @@ Related information: ## Next steps -- [Configure GitHub Actions](configure-github-actions.md) to run these checks automatically - Customize linting rules to match your team's style preferences - Explore advanced type checking features diff --git a/content/guides/python/secure-supply-chain.md b/content/guides/python/secure-supply-chain.md deleted file mode 100644 index 07c8b3f0ca60..000000000000 --- a/content/guides/python/secure-supply-chain.md +++ /dev/null @@ -1,144 +0,0 @@ ---- -title: Secure your Python image supply chain -linkTitle: Secure your supply chain -weight: 45 -keywords: python, sbom, provenance, attestations, docker scout, supply chain, security -description: Learn how to inspect, generate, and verify supply chain attestations for your Python container image. ---- - -## Prerequisites - -Complete [Configure CI/CD for your Python application](configure-github-actions.md). - -## Overview - -When you ship a container image, what's inside it and where it came from -matters. Supply chain attestations are signed records that answer questions -like which packages are in the image, what vulnerabilities affect them, how -the image was built, and what security checks it passed. - -In this section, you'll inspect the attestations that ship with your Docker -Hardened Image base, generate your own SBOM and provenance attestations -during CI, and pin the base image by digest so your builds are reproducible. - -The inspection commands in this topic are shown manually so you can see what -each one returns. In a real workflow you'd automate these checks with -[Docker Scout](/scout/), which runs the same scans on every push, -enforces policies in CI, and surfaces results in your registry and pull -requests. - -## Inspect the base image attestations - -Docker Hardened Images are built to SLSA Build Level 3 and ship with a set of -signed attestations covering bill-of-materials, vulnerabilities, build -provenance, and security scans. See -[DHI attestations](/manuals/dhi/core-concepts/attestations.md) for the full -list of types and how to verify their signatures with Cosign. - -List all the attestations available on the Python DHI: - -```console -$ docker scout attest list registry://dhi.io/python:3.12 -``` - -View the SBOM: - -```console -$ docker scout sbom registry://dhi.io/python:3.12 -``` - -Check known vulnerabilities: - -```console -$ docker scout cves registry://dhi.io/python:3.12 -``` - -> [!NOTE] -> -> The `registry://` prefix forces `docker scout` to fetch the image and its -> attestations from the registry instead of reading a locally pulled copy. If -> you've already pulled or built against the base image, the local copy -> doesn't have the attached attestations, so the prefix is required to see -> them. - -When you base your own image on a DHI image, these attestations stay attached to the base layer in the registry. Tools that inspect your image can follow the chain back to the DHI source. - -## Generate attestations for your image - -Update your GitHub Actions workflow to attach SBOM and provenance attestations to the image you push. - -Edit `.github/workflows/build.yml` and update the build-and-push step: - -```yaml {hl_lines="6-7"} -- name: Build and push Docker image - uses: docker/build-push-action@v6 - with: - context: . - push: true - sbom: true - provenance: mode=max - tags: ${{ steps.meta.outputs.tags }} -``` - -- `sbom: true` tells BuildKit to scan the built image and attach an SBOM attestation. -- `provenance: mode=max` records detailed build provenance, including the source repository, commit, and build parameters. - -The next time your workflow runs, the pushed image will carry these attestations alongside the image manifest in the registry. - -## Inspect your pushed image's attestations - -After your workflow pushes the image, inspect it the same way you inspected the base image: - -```console -$ docker scout attest list registry://DOCKER_USERNAME/REPO_NAME:latest -$ docker scout sbom registry://DOCKER_USERNAME/REPO_NAME:latest -``` - -The SBOM includes packages from every layer, including those inherited from `dhi.io/python:3.12`. The provenance record references the DHI base image by digest, so consumers of your image can trace the build chain back to the DHI source. - -## Pin the base image by digest - -Image tags like `dhi.io/python:3.12` move over time as new patches land. For reproducible builds, pin to an immutable digest. - -The Dockerfile uses two tags, `dhi.io/python:3.12-dev` in the builder stage -and `dhi.io/python:3.12` in the runtime stage. Each tag has its own digest, -so look up both: - -```console -$ docker buildx imagetools inspect dhi.io/python:3.12-dev --format "{{ .Manifest.Digest }}" -sha256:4f53cda18c2baa0c0354bb5f9a3ecbe5ed12ab4d8e11ba873c2f11161202b945 -$ docker buildx imagetools inspect dhi.io/python:3.12 --format "{{ .Manifest.Digest }}" -sha256:e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 -``` - -Each digest is a 64-character hex string. Update your `Dockerfile` to reference -each digest on the matching `FROM` line: - -```dockerfile -FROM dhi.io/python:3.12-dev@sha256:4f53cda18c2baa0c0354bb5f9a3ecbe5ed12ab4d8e11ba873c2f11161202b945 AS builder -# ... -FROM dhi.io/python:3.12@sha256:e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 -``` - -> [!TIP] -> -> Pinning by digest also pins you to that image's vulnerabilities. Use [Dependabot](https://docs.github.com/en/code-security/dependabot) or [Renovate](https://docs.renovatebot.com/) to automate digest updates so you get a PR when a new patched image is available, with a changelog to review before merging. - -## Summary - -In this section, you learned how to: - -- Inspect the supply chain attestations that ship with the DHI base image, including SBOMs, CVE reports, VEX statements, and scan results -- Generate SBOM and provenance attestations for your own image in CI -- Pin base images by digest for reproducible builds - -Related information: - -- [DHI attestations](/manuals/dhi/core-concepts/attestations.md) -- [Verify a Docker Hardened Image](/manuals/dhi/how-to/verify.md) -- [Docker Scout](/scout/) -- [Build attestations](/manuals/build/metadata/attestations/_index.md) - -## Next steps - -In the next section, you'll deploy your application to Kubernetes. diff --git a/content/guides/r/_index.md b/content/guides/r/_index.md index c599db41a572..87c1a1795cd1 100644 --- a/content/guides/r/_index.md +++ b/content/guides/r/_index.md @@ -19,7 +19,5 @@ The R language-specific guide teaches you how to containerize a R application us - Containerize and run a R application - Set up a local environment to develop a R application using containers -- Configure a CI/CD pipeline for a containerized R application using GitHub Actions -- Deploy your containerized R application locally to Kubernetes to test and debug your deployment Start by containerizing an existing R application. diff --git a/content/guides/r/configure-ci-cd.md b/content/guides/r/configure-ci-cd.md deleted file mode 100644 index 662a2155e14b..000000000000 --- a/content/guides/r/configure-ci-cd.md +++ /dev/null @@ -1,133 +0,0 @@ ---- -title: Configure CI/CD for your R application -linkTitle: Configure CI/CD -weight: 40 -keywords: ci/cd, github actions, R, shiny -description: Learn how to configure CI/CD using GitHub Actions for your R application. -aliases: - - /language/r/configure-ci-cd/ - - /guides/language/r/configure-ci-cd/ ---- - -## Prerequisites - -Complete all the previous sections of this guide, starting with [Containerize a R application](containerize.md). You must have a [GitHub](https://github.com/signup) account and a verified [Docker](https://hub.docker.com/signup) account to complete this section. - -## Overview - -In this section, you'll learn how to set up and use GitHub Actions to build and test your Docker image as well as push it to Docker Hub. You will complete the following steps: - -1. Create a new repository on GitHub. -2. Define the GitHub Actions workflow. -3. Run the workflow. - -## Step one: Create the repository - -Create a GitHub repository, configure the Docker Hub credentials, and push your source code. - -1. [Create a new repository](https://github.com/new) on GitHub. - -2. Open the repository **Settings**, and go to **Secrets and variables** > - **Actions**. - -3. Create a new **Repository variable** named `DOCKER_USERNAME` and your Docker ID as a value. - -4. Create a new [Personal Access Token (PAT)](/manuals/security/access-tokens.md#create-an-access-token) for Docker Hub. You can name this token `docker-tutorial`. Make sure access permissions include Read and Write. - -5. Add the PAT as a **Repository secret** in your GitHub repository, with the name - `DOCKERHUB_TOKEN`. - -6. In your local repository on your machine, run the following command to change - the origin to the repository you just created. Make sure you change - `your-username` to your GitHub username and `your-repository` to the name of - the repository you created. - - ```console - $ git remote set-url origin https://github.com/your-username/your-repository.git - ``` - -7. Run the following commands to stage, commit, and push your local repository to GitHub. - - ```console - $ git add -A - $ git commit -m "my commit" - $ git push -u origin main - ``` - -## Step two: Set up the workflow - -Set up your GitHub Actions workflow for building, testing, and pushing the image -to Docker Hub. - -1. Go to your repository on GitHub and then select the **Actions** tab. - -2. Select **set up a workflow yourself**. - - This takes you to a page for creating a new GitHub actions workflow file in - your repository, under `.github/workflows/main.yml` by default. - -3. In the editor window, copy and paste the following YAML configuration. - - ```yaml - name: ci - - on: - push: - branches: - - main - - jobs: - build: - runs-on: ubuntu-latest - steps: - - name: Login to Docker Hub - uses: docker/login-action@{{% param "login_action_version" %}} - with: - username: ${{ vars.DOCKER_USERNAME }} - password: ${{ secrets.DOCKERHUB_TOKEN }} - - - name: Set up Docker Buildx - uses: docker/setup-buildx-action@{{% param "setup_buildx_action_version" %}} - - - name: Build and push - uses: docker/build-push-action@{{% param "build_push_action_version" %}} - with: - platforms: linux/amd64,linux/arm64 - push: true - tags: ${{ vars.DOCKER_USERNAME }}/${{ github.event.repository.name }}:latest - ``` - - For more information about the YAML syntax for `docker/build-push-action`, - refer to the [GitHub Action README](https://github.com/docker/build-push-action/blob/master/README.md). - -## Step three: Run the workflow - -Save the workflow file and run the job. - -1. Select **Commit changes...** and push the changes to the `main` branch. - - After pushing the commit, the workflow starts automatically. - -2. Go to the **Actions** tab. It displays the workflow. - - Selecting the workflow shows you the breakdown of all the steps. - -3. When the workflow is complete, go to your - [repositories on Docker Hub](https://hub.docker.com/repositories). - - If you see the new repository in that list, it means the GitHub Actions - successfully pushed the image to Docker Hub. - -## Summary - -In this section, you learned how to set up a GitHub Actions workflow for your R application. - -Related information: - -- [Introduction to GitHub Actions](/guides/gha.md) -- [Docker Build GitHub Actions](/manuals/build/ci/github-actions/_index.md) -- [Workflow syntax for GitHub Actions](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions) - -## Next steps - -Next, learn how you can locally test and debug your workloads on Kubernetes before deploying. diff --git a/content/guides/r/deploy.md b/content/guides/r/deploy.md deleted file mode 100644 index 70c10b216faa..000000000000 --- a/content/guides/r/deploy.md +++ /dev/null @@ -1,147 +0,0 @@ ---- -title: Test your R deployment -linkTitle: Test your deployment -weight: 50 -keywords: deploy, kubernetes, R -description: Learn how to develop locally using Kubernetes -aliases: - - /language/r/deploy/ - - /guides/language/r/deploy/ ---- - -## Prerequisites - -- Complete all the previous sections of this guide, starting with [Containerize a R application](containerize.md). -- [Turn on Kubernetes](/manuals/desktop/use-desktop/kubernetes.md#enable-kubernetes) in Docker Desktop. - -## Overview - -In this section, you'll learn how to use Docker Desktop to deploy your application to a fully-featured Kubernetes environment on your development machine. This allows you to test and debug your workloads on Kubernetes locally before deploying. - -## Create a Kubernetes YAML file - -In your `r-docker-dev` directory, create a file named -`docker-r-kubernetes.yaml`. Open the file in an IDE or text editor and add -the following contents. Replace `DOCKER_USERNAME/REPO_NAME` with your Docker -username and the name of the repository that you created in [Configure CI/CD for -your R application](configure-ci-cd.md). - -```yaml -apiVersion: apps/v1 -kind: Deployment -metadata: - name: docker-r-demo - namespace: default -spec: - replicas: 1 - selector: - matchLabels: - service: shiny - template: - metadata: - labels: - service: shiny - spec: - containers: - - name: shiny-service - image: DOCKER_USERNAME/REPO_NAME - imagePullPolicy: Always - env: - - name: POSTGRES_PASSWORD - value: mysecretpassword ---- -apiVersion: v1 -kind: Service -metadata: - name: service-entrypoint - namespace: default -spec: - type: NodePort - selector: - service: shiny - ports: - - port: 3838 - targetPort: 3838 - nodePort: 30001 -``` - -In this Kubernetes YAML file, there are two objects, separated by the `---`: - -- A Deployment, describing a scalable group of identical pods. In this case, - you'll get just one replica, or copy of your pod. That pod, which is - described under `template`, has just one container in it. The - container is created from the image built by GitHub Actions in [Configure CI/CD for - your R application](configure-ci-cd.md). -- A NodePort service, which will route traffic from port 30001 on your host to - port 3838 inside the pods it routes to, allowing you to reach your app - from the network. - -To learn more about Kubernetes objects, see the [Kubernetes documentation](https://kubernetes.io/docs/home/). - -## Deploy and check your application - -1. In a terminal, navigate to `r-docker-dev` and deploy your application to - Kubernetes. - - ```console - $ kubectl apply -f docker-r-kubernetes.yaml - ``` - - You should see output that looks like the following, indicating your Kubernetes objects were created successfully. - - ```text - deployment.apps/docker-r-demo created - service/service-entrypoint created - ``` - -2. Make sure everything worked by listing your deployments. - - ```console - $ kubectl get deployments - ``` - - Your deployment should be listed as follows: - - ```shell - NAME READY UP-TO-DATE AVAILABLE AGE - docker-r-demo 1/1 1 1 15s - ``` - - This indicates all one of the pods you asked for in your YAML are up and running. Do the same check for your services. - - ```console - $ kubectl get services - ``` - - You should get output like the following. - - ```shell - NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE - kubernetes ClusterIP 10.96.0.1 443/TCP 23h - service-entrypoint NodePort 10.99.128.230 3838:30001/TCP 75s - ``` - - In addition to the default `kubernetes` service, you can see your `service-entrypoint` service, accepting traffic on port 30001/TCP. - -3. In a browser, visit the following address. Note that a database was not deployed in - this example. - - ```console - http://localhost:30001/ - ``` - -4. Run the following command to tear down your application. - - ```console - $ kubectl delete -f docker-r-kubernetes.yaml - ``` - -## Summary - -In this section, you learned how to use Docker Desktop to deploy your application to a fully-featured Kubernetes environment on your development machine. - -Related information: - -- [Kubernetes documentation](https://kubernetes.io/docs/home/) -- [Deploy on Kubernetes with Docker Desktop](/manuals/desktop/use-desktop/kubernetes.md) -- [Swarm mode overview](/manuals/engine/swarm/_index.md) diff --git a/content/guides/r/develop.md b/content/guides/r/develop.md index 0427464e298a..589253e72e36 100644 --- a/content/guides/r/develop.md +++ b/content/guides/r/develop.md @@ -216,6 +216,3 @@ Related information: - [Compose file watch](/manuals/compose/how-tos/file-watch.md) - [Multi-stage builds](/manuals/build/building/multi-stage.md) -## Next steps - -In the next section, you'll take a look at how to set up a CI/CD pipeline using GitHub Actions. diff --git a/content/guides/reactjs/_index.md b/content/guides/reactjs/_index.md index 10024e063f5e..7b8251ce3871 100644 --- a/content/guides/reactjs/_index.md +++ b/content/guides/reactjs/_index.md @@ -31,8 +31,6 @@ In this guide, you will learn how to: - Containerize and run a React.js application using Docker. - Set up a local development environment for React.js inside a container. - Run tests for your React.js application within a Docker container. -- Configure a CI/CD pipeline using GitHub Actions for your containerized app. -- Deploy the containerized React.js application to a local Kubernetes cluster for testing and debugging. To begin, you’ll start by containerizing an existing React.js application. diff --git a/content/guides/reactjs/configure-github-actions.md b/content/guides/reactjs/configure-github-actions.md deleted file mode 100644 index 158506c13462..000000000000 --- a/content/guides/reactjs/configure-github-actions.md +++ /dev/null @@ -1,321 +0,0 @@ ---- -title: Automate your builds with GitHub Actions -linkTitle: GitHub Actions CI -weight: 60 -keywords: CI/CD, GitHub( Actions), React.js, Next.js -description: Learn how to configure CI/CD using GitHub Actions for your React.js application. - ---- - -## Prerequisites - -Complete all the previous sections of this guide, starting with [Containerize React.js application](containerize.md). - -You must also have: -- A [GitHub](https://github.com/signup) account. -- A verified [Docker Hub](https://hub.docker.com/signup) account. - ---- - -## Overview - -In this section, you'll set up a CI/CD pipeline using [GitHub Actions](https://docs.github.com/en/actions) to automatically: - -- Build your React.js application inside a Docker container. -- Run tests in a consistent environment. -- Push the production-ready image to [Docker Hub](https://hub.docker.com). - ---- - -## Connect your GitHub repository to Docker Hub - -To enable GitHub Actions to build and push Docker images, you’ll securely store your Docker Hub credentials in your new GitHub repository. - -### Step 1: Connect your GitHub repository to Docker Hub - -1. Create a Personal Access Token (PAT) from [Docker Hub](https://hub.docker.com) - 1. Go to your **Docker Hub account → Account Settings → Security**. - 2. Generate a new Access Token with **Read/Write** permissions. - 3. Name it something like `docker-reactjs-sample`. - 4. Copy and save the token — you’ll need it in Step 4. - -2. Create a repository in [Docker Hub](https://hub.docker.com/repositories/) - 1. Go to your **Docker Hub account → Create a repository**. - 2. For the Repository Name, use something descriptive — for example: `reactjs-sample`. - 3. Once created, copy and save the repository name — you’ll need it in Step 4. - -3. Create a new [GitHub repository](https://github.com/new) for your React.js project - -4. Add Docker Hub credentials as GitHub repository secrets - - In your newly created GitHub repository: - - 1. Navigate to: - **Settings → Secrets and variables → Actions → New repository secret**. - - 2. Add the following secrets: - - | Name | Value | - |-------------------|--------------------------------| - | `DOCKER_USERNAME` | Your Docker Hub username | - | `DOCKERHUB_TOKEN` | Your Docker Hub access token (created in Step 1) | - | `DOCKERHUB_PROJECT_NAME` | Your Docker Project Name (created in Step 2) | - - These secrets let GitHub Actions to authenticate securely with Docker Hub during automated workflows. - -5. Connect Your Local Project to GitHub - - Link your local project `docker-reactjs-sample` to the GitHub repository you just created by running the following command from your project root: - - ```console - $ git remote set-url origin https://github.com/{your-username}/{your-repository-name}.git - ``` - - >[!IMPORTANT] - >Replace `{your-username}` and `{your-repository}` with your actual GitHub username and repository name. - - To confirm that your local project is correctly connected to the remote GitHub repository, run: - - ```console - $ git remote -v - ``` - - You should see output similar to: - - ```console - origin https://github.com/{your-username}/{your-repository-name}.git (fetch) - origin https://github.com/{your-username}/{your-repository-name}.git (push) - ``` - - This confirms that your local repository is properly linked and ready to push your source code to GitHub. - -6. Push Your Source Code to GitHub - - Follow these steps to commit and push your local project to your GitHub repository: - - 1. Stage all files for commit. - - ```console - $ git add -A - ``` - This command stages all changes — including new, modified, and deleted files — preparing them for commit. - - - 2. Commit your changes. - - ```console - $ git commit -m "Initial commit" - ``` - This command creates a commit that snapshots the staged changes with a descriptive message. - - 3. Push the code to the `main` branch. - - ```console - $ git push -u origin main - ``` - This command pushes your local commits to the `main` branch of the remote GitHub repository and sets the upstream branch. - -Once completed, your code will be available on GitHub, and any GitHub Actions workflow you’ve configured will run automatically. - -> [!NOTE] -> Learn more about the Git commands used in this step: -> - [Git add](https://git-scm.com/docs/git-add) – Stage changes (new, modified, deleted) for commit -> - [Git commit](https://git-scm.com/docs/git-commit) – Save a snapshot of your staged changes -> - [Git push](https://git-scm.com/docs/git-push) – Upload local commits to your GitHub repository -> - [Git remote](https://git-scm.com/docs/git-remote) – View and manage remote repository URLs - ---- - -### Step 2: Set up the workflow - -Now you'll create a GitHub Actions workflow that builds your Docker image, runs tests, and pushes the image to Docker Hub. - -1. Go to your repository on GitHub and select the **Actions** tab in the top menu. - -2. Select **Set up a workflow yourself** when prompted. - - This opens an inline editor to create a new workflow file. By default, it will be saved to: - `.github/workflows/main.yml` - - -3. Add the following workflow configuration to the new file: - -```yaml -name: CI/CD – React.js Application with Docker - -on: - push: - branches: [main] - pull_request: - branches: [main] - types: [opened, synchronize, reopened] - -jobs: - build-test-push: - name: Build, Test and Push Docker Image - runs-on: ubuntu-latest - - steps: - # 1. Checkout source code - - name: Checkout source code - uses: actions/checkout@{{% param "checkout_action_version" %}} - with: - fetch-depth: 0 # Fetches full history for better caching/context - - # 2. Set up Docker Buildx - - name: Set up Docker Buildx - uses: docker/setup-buildx-action@{{% param "setup_buildx_action_version" %}} - - # 3. Cache Docker layers - - name: Cache Docker layers - uses: actions/cache@{{% param "cache_action_version" %}} - with: - path: /tmp/.buildx-cache - key: ${{ runner.os }}-buildx-${{ github.sha }} - restore-keys: ${{ runner.os }}-buildx- - - # 4. Cache npm dependencies - - name: Cache npm dependencies - uses: actions/cache@{{% param "cache_action_version" %}} - with: - path: ~/.npm - key: ${{ runner.os }}-npm-${{ hashFiles('**/package-lock.json') }} - restore-keys: ${{ runner.os }}-npm- - - # 5. Extract metadata - - name: Extract metadata - id: meta - run: | - echo "REPO_NAME=${GITHUB_REPOSITORY##*/}" >> "$GITHUB_OUTPUT" - echo "SHORT_SHA=${GITHUB_SHA::7}" >> "$GITHUB_OUTPUT" - - # 6. Build dev Docker image - - name: Build Docker image for tests - uses: docker/build-push-action@{{% param "build_push_action_version" %}} - with: - context: . - file: Dockerfile.dev - tags: ${{ steps.meta.outputs.REPO_NAME }}-dev:latest - load: true # Load to local Docker daemon for testing - cache-from: type=local,src=/tmp/.buildx-cache - cache-to: type=local,dest=/tmp/.buildx-cache,mode=max - - # 7. Run Vitest tests - - name: Run Vitest tests and generate report - run: | - docker run --rm \ - --workdir /app \ - --entrypoint "" \ - ${{ steps.meta.outputs.REPO_NAME }}-dev:latest \ - sh -c "npm ci && npx vitest run --reporter=verbose" - env: - CI: true - NODE_ENV: test - timeout-minutes: 10 - - # 8. Login to Docker Hub - - name: Log in to Docker Hub - uses: docker/login-action@{{% param "login_action_version" %}} - with: - username: ${{ secrets.DOCKER_USERNAME }} - password: ${{ secrets.DOCKERHUB_TOKEN }} - - # 9. Build and push prod image - - name: Build and push production image - uses: docker/build-push-action@{{% param "build_push_action_version" %}} - with: - context: . - file: Dockerfile - push: true - platforms: linux/amd64,linux/arm64 - tags: | - ${{ secrets.DOCKER_USERNAME }}/${{ secrets.DOCKERHUB_PROJECT_NAME }}:latest - ${{ secrets.DOCKER_USERNAME }}/${{ secrets.DOCKERHUB_PROJECT_NAME }}:${{ steps.meta.outputs.SHORT_SHA }} - cache-from: type=local,src=/tmp/.buildx-cache -``` - -This workflow performs the following tasks for your React.js application: -- Triggers on every `push` or `pull request` targeting the `main` branch. -- Builds a development Docker image using `Dockerfile.dev`, optimized for testing. -- Executes unit tests using Vitest inside a clean, containerized environment to ensure consistency. -- Halts the workflow immediately if any test fails — enforcing code quality. -- Caches both Docker build layers and npm dependencies for faster CI runs. -- Authenticates securely with Docker Hub using GitHub repository secrets. -- Builds a production-ready image using the `prod` stage in `Dockerfile`. -- Tags and pushes the final image to Docker Hub with both `latest` and short SHA tags for traceability. - -> [!NOTE] -> For more information about `docker/build-push-action`, refer to the [GitHub Action README](https://github.com/docker/build-push-action/blob/master/README.md). - ---- - -### Step 3: Run the workflow - -After you've added your workflow file, it's time to trigger and observe the CI/CD process in action. - -1. Commit and push your workflow file - - Select "Commit changes…" in the GitHub editor. - - - This push will automatically trigger the GitHub Actions pipeline. - -2. Monitor the workflow execution - - 1. Go to the Actions tab in your GitHub repository. - 2. Select the workflow run to follow each step: `build`, `test`, and (if successful) `push`. - -3. Verify the Docker image on Docker Hub - - - After a successful workflow run, visit your [Docker Hub repositories](https://hub.docker.com/repositories). - - You should see a new image under your repository with: - - Repository name: `${your-repository-name}` - - Tags include: - - `latest` – represents the most recent successful build; ideal for quick testing or deployment. - - `` – a unique identifier based on the commit hash, useful for version tracking, rollbacks, and traceability. - -> [!TIP] Protect your main branch -> To maintain code quality and prevent accidental direct pushes, enable branch protection rules: -> - Navigate to your **GitHub repo → Settings → Branches**. -> - Under Branch protection rules, click **Add rule**. -> - Specify `main` as the branch name. -> - Enable options like: -> - *Require a pull request before merging*. -> - *Require status checks to pass before merging*. -> -> This ensures that only tested and reviewed code is merged into `main` branch. ---- - -## Summary - -In this section, you set up a complete CI/CD pipeline for your containerized React.js application using GitHub Actions. - -Here's what you accomplished: - -- Created a new GitHub repository specifically for your project. -- Generated a secure Docker Hub access token and added it to GitHub as a secret. -- Defined a GitHub Actions workflow to: - - Build your application inside a Docker container. - - Run tests in a consistent, containerized environment. - - Push a production-ready image to Docker Hub if tests pass. -- Triggered and verified the workflow execution through GitHub Actions. -- Confirmed that your image was successfully published to Docker Hub. - -With this setup, your React.js application is now ready for automated testing and deployment across environments — increasing confidence, consistency, and team productivity. - ---- - -## Related resources - -Deepen your understanding of automation and best practices for containerized apps: - -- [Introduction to GitHub Actions](/guides/gha.md) – Learn how GitHub Actions automate your workflows -- [Docker Build GitHub Actions](/manuals/build/ci/github-actions/_index.md) – Set up container builds with GitHub Actions -- [Workflow syntax for GitHub Actions](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions) – Full reference for writing GitHub workflows -- [Compose file reference](/compose/compose-file/) – Full configuration reference for `compose.yaml` -- [Best practices for writing Dockerfiles](/develop/develop-images/dockerfile_best-practices/) – Optimize your image for performance and security - ---- - -## Next steps - -Next, learn how you can locally test and debug your React.js workloads on Kubernetes before deploying. This helps you ensure your application behaves as expected in a production-like environment, reducing surprises during deployment. diff --git a/content/guides/reactjs/deploy.md b/content/guides/reactjs/deploy.md deleted file mode 100644 index 37e6a256e0a2..000000000000 --- a/content/guides/reactjs/deploy.md +++ /dev/null @@ -1,194 +0,0 @@ ---- -title: Test your React.js deployment -linkTitle: Test your deployment -weight: 60 -keywords: deploy, kubernetes, react, react.js -description: Learn how to deploy locally to test and debug your Kubernetes deployment - ---- - -## Prerequisites - -Before you begin, make sure you’ve completed the following: -- Complete all the previous sections of this guide, starting with [Containerize React.js application](containerize.md). -- [Enable Kubernetes](/manuals/desktop/use-desktop/kubernetes.md#enable-kubernetes) in Docker Desktop. - -> **New to Kubernetes?** -> Visit the [Kubernetes basics tutorial](https://kubernetes.io/docs/tutorials/kubernetes-basics/) to get familiar with how clusters, pods, deployments, and services work. - ---- - -## Overview - -This section guides you through deploying your containerized React.js application locally using [Docker Desktop’s built-in Kubernetes](/desktop/kubernetes/). Running your app in a local Kubernetes cluster allows you to closely simulate a real production environment, enabling you to test, validate, and debug your workloads with confidence before promoting them to staging or production. - ---- - -## Create a Kubernetes YAML file - -Follow these steps to define your deployment configuration: - -1. In the root of your project, create a new file named: reactjs-sample-kubernetes.yaml - -2. Open the file in your IDE or preferred text editor. - -3. Add the following configuration, and be sure to replace `{DOCKER_USERNAME}` and `{DOCKERHUB_PROJECT_NAME}` with your actual Docker Hub username and repository name from the previous [Automate your builds with GitHub Actions](configure-github-actions.md). - - -```yaml -apiVersion: apps/v1 -kind: Deployment -metadata: - name: reactjs-sample - namespace: default -spec: - replicas: 1 - selector: - matchLabels: - app: reactjs-sample - template: - metadata: - labels: - app: reactjs-sample - spec: - containers: - - name: reactjs-container - image: {DOCKER_USERNAME}/{DOCKERHUB_PROJECT_NAME}:latest - imagePullPolicy: Always - ports: - - containerPort: 8080 ---- -apiVersion: v1 -kind: Service -metadata: - name: reactjs-sample-service - namespace: default -spec: - type: NodePort - selector: - app: reactjs-sample - ports: - - port: 8080 - targetPort: 8080 - nodePort: 30001 -``` - -This manifest defines two key Kubernetes resources, separated by `---`: - -- Deployment - Deploys a single replica of your React.js application inside a pod. The pod uses the Docker image built and pushed by your GitHub Actions CI/CD workflow - (refer to [Automate your builds with GitHub Actions](configure-github-actions.md)). - The container listens on port `8080`, which is typically used by [Nginx](https://nginx.org/en/docs/) to serve your production React app. - -- Service (NodePort) - Exposes the deployed pod to your local machine. - It forwards traffic from port `30001` on your host to port `8080` inside the container. - This lets you access the application in your browser at [http://localhost:30001](http://localhost:30001). - -> [!NOTE] -> To learn more about Kubernetes objects, see the [Kubernetes documentation](https://kubernetes.io/docs/home/). - ---- - -## Deploy and check your application - -Follow these steps to deploy your containerized React.js app into a local Kubernetes cluster and verify that it’s running correctly. - -### Step 1. Apply the Kubernetes configuration - -In your terminal, navigate to the directory where your `reactjs-sample-kubernetes.yaml` file is located, then deploy the resources using: - -```console - $ kubectl apply -f reactjs-sample-kubernetes.yaml -``` - -If everything is configured properly, you’ll see confirmation that both the Deployment and the Service were created: - -```shell - deployment.apps/reactjs-sample created - service/reactjs-sample-service created -``` - -This output means that both the Deployment and the Service were successfully created and are now running inside your local cluster. - -### Step 2. Check the deployment status - -Run the following command to check the status of your deployment: - -```console - $ kubectl get deployments -``` - -You should see an output similar to: - -```shell - NAME READY UP-TO-DATE AVAILABLE AGE - reactjs-sample 1/1 1 1 14s -``` - -This confirms that your pod is up and running with one replica available. - -### Step 3. Verify the service exposure - -Check if the NodePort service is exposing your app to your local machine: - -```console -$ kubectl get services -``` - -You should see something like: - -```shell -NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE -reactjs-sample-service NodePort 10.100.244.65 8080:30001/TCP 1m -``` - -This output confirms that your app is available via NodePort on port 30001. - -### Step 4. Access your app in the browser - -Open your browser and navigate to [http://localhost:30001](http://localhost:30001). - -You should see your production-ready React.js Sample application running — served by your local Kubernetes cluster. - -### Step 5. Clean up Kubernetes resources - -Once you're done testing, you can delete the deployment and service using: - -```console - $ kubectl delete -f reactjs-sample-kubernetes.yaml -``` - -Expected output: - -```shell - deployment.apps "reactjs-sample" deleted - service "reactjs-sample-service" deleted -``` - -This ensures your cluster stays clean and ready for the next deployment. - ---- - -## Summary - -In this section, you learned how to deploy your React.js application to a local Kubernetes cluster using Docker Desktop. This setup allows you to test and debug your containerized app in a production-like environment before deploying it to the cloud. - -What you accomplished: - -- Created a Kubernetes Deployment and NodePort Service for your React.js app -- Used `kubectl apply` to deploy the application locally -- Verified the app was running and accessible at `http://localhost:30001` -- Cleaned up your Kubernetes resources after testing - ---- - -## Related resources - -Explore official references and best practices to sharpen your Kubernetes deployment workflow: - -- [Kubernetes documentation](https://kubernetes.io/docs/home/) – Learn about core concepts, workloads, services, and more. -- [Deploy on Kubernetes with Docker Desktop](/manuals/desktop/use-desktop/kubernetes.md) – Use Docker Desktop’s built-in Kubernetes support for local testing and development. -- [`kubectl` CLI reference](https://kubernetes.io/docs/reference/kubectl/) – Manage Kubernetes clusters from the command line. -- [Kubernetes Deployment resource](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/) – Understand how to manage and scale applications using Deployments. -- [Kubernetes Service resource](https://kubernetes.io/docs/concepts/services-networking/service/) – Learn how to expose your application to internal and external traffic. \ No newline at end of file diff --git a/content/guides/reactjs/run-tests.md b/content/guides/reactjs/run-tests.md index dc72025d43f4..fdcedba1e951 100644 --- a/content/guides/reactjs/run-tests.md +++ b/content/guides/reactjs/run-tests.md @@ -174,6 +174,3 @@ Explore official references and best practices to sharpen your Docker testing wo - [`docker compose run` CLI reference](/reference/cli/docker/compose/run/) – Run one-off commands in a service container. --- -## Next steps - -Next, you’ll learn how to set up a CI/CD pipeline using GitHub Actions to automatically build and test your React.js application in a containerized environment. This ensures your code is validated on every push or pull request, maintaining consistency and reliability across your development workflow. diff --git a/content/guides/ruby/_index.md b/content/guides/ruby/_index.md index 5652dc7fe5b2..f241e8091fc7 100644 --- a/content/guides/ruby/_index.md +++ b/content/guides/ruby/_index.md @@ -20,8 +20,6 @@ params: The Ruby language-specific guide teaches you how to containerize a Ruby on Rails application using Docker. In this guide, you’ll learn how to: - Containerize and run a Ruby on Rails application -- Configure a GitHub Actions workflow to build and push a Docker image to Docker Hub - Set up a local environment to develop a Ruby on Rails application using containers -- Deploy your containerized Ruby on Rails application locally to Kubernetes to test and debug your deployment Start by containerizing an existing Ruby on Rails application. diff --git a/content/guides/ruby/configure-github-actions.md b/content/guides/ruby/configure-github-actions.md deleted file mode 100644 index 0485bb00eeb4..000000000000 --- a/content/guides/ruby/configure-github-actions.md +++ /dev/null @@ -1,111 +0,0 @@ ---- -title: Automate your builds with GitHub Actions -linkTitle: GitHub Actions CI -weight: 20 -keywords: ci/cd, github actions, ruby, flask -description: Learn how to configure CI/CD using GitHub Actions for your Ruby on Rails application. -aliases: - - /language/ruby/configure-ci-cd/ - - /guides/language/ruby/configure-ci-cd/ - - /guides/ruby/configure-ci-cd/ ---- - -## Prerequisites - -Complete all the previous sections of this guide, starting with [Containerize a Ruby on Rails application](containerize.md). You must have a [GitHub](https://github.com/signup) account and a verified [Docker](https://hub.docker.com/signup) account to complete this section. - -If you didn't create a [GitHub repository](https://github.com/new) for your project yet, it is time to do it. After creating the repository, don't forget to [add a remote](https://docs.github.com/en/get-started/getting-started-with-git/managing-remote-repositories) and ensure you can commit and [push your code](https://docs.github.com/en/get-started/using-git/pushing-commits-to-a-remote-repository#about-git-push) to GitHub. - -1. In your project's GitHub repository, open **Settings**, and go to **Secrets and variables** > **Actions**. - -2. Under the **Variables** tab, create a new **Repository variable** named `DOCKER_USERNAME` and your Docker ID as a value. - -3. Create a new [Personal Access Token (PAT)](/manuals/security/access-tokens.md#create-an-access-token) for Docker Hub. You can name this token `docker-tutorial`. Make sure access permissions include Read and Write. - -4. Add the PAT as a **Repository secret** in your GitHub repository, with the name - `DOCKERHUB_TOKEN`. - -## Overview - -GitHub Actions is a CI/CD (Continuous Integration and Continuous Deployment) automation tool built into GitHub. It allows you to define custom workflows for building, testing, and deploying your code when specific events occur (e.g., pushing code, creating a pull request, etc.). A workflow is a YAML-based automation script that defines a sequence of steps to be executed when triggered. Workflows are stored in the `.github/workflows/` directory of a repository. - -In this section, you'll learn how to set up and use GitHub Actions to build your Docker image as well as push it to Docker Hub. You will complete the following steps: - -1. Define the GitHub Actions workflow. -2. Run the workflow. - -## 1. Define the GitHub Actions workflow - -You can create a GitHub Actions workflow by creating a YAML file in the `.github/workflows/` directory of your repository. To do this use your favorite text editor or the GitHub web interface. The following steps show you how to create a workflow file using the GitHub web interface. - -If you prefer to use the GitHub web interface, follow these steps: - -1. Go to your repository on GitHub and then select the **Actions** tab. - -2. Select **set up a workflow yourself**. - - This takes you to a page for creating a new GitHub Actions workflow file in - your repository. By default, the file is created under `.github/workflows/main.yml`, let's change it name to `build.yml`. - -If you prefer to use your text editor, create a new file named `build.yml` in the `.github/workflows/` directory of your repository. - -Add the following content to the file: - -```yaml -name: Build and push Docker image - -on: - push: - branches: - - main - -jobs: - build_and_push: - runs-on: ubuntu-latest - steps: - - name: Login to Docker Hub - uses: docker/login-action@{{% param "login_action_version" %}} - with: - username: ${{ vars.DOCKER_USERNAME }} - password: ${{ secrets.DOCKERHUB_TOKEN }} - - - name: Set up Docker Buildx - uses: docker/setup-buildx-action@{{% param "setup_buildx_action_version" %}} - - - name: Build and push - uses: docker/build-push-action@{{% param "build_push_action_version" %}} - with: - push: true - tags: ${{ vars.DOCKER_USERNAME }}/${{ github.event.repository.name }}:latest -``` - -Each GitHub Actions workflow includes one or several jobs. Each job consists of steps. Each step can either run a set of commands or use already [existing actions](https://github.com/marketplace?type=actions). The action above has three steps: - -1. [Login to Docker Hub](https://github.com/docker/login-action): Action logs in to Docker Hub using the Docker ID and Personal Access Token (PAT) you created earlier. - -2. [Set up Docker Buildx](https://github.com/docker/setup-buildx-action): Action sets up Docker [Buildx](https://github.com/docker/buildx), a CLI plugin that extends the capabilities of the Docker CLI. - -3. [Build and push](https://github.com/docker/build-push-action): Action builds and pushes the Docker image to Docker Hub. The `tags` parameter specifies the image name and tag. The `latest` tag is used in this example. - -## 2. Run the workflow - -Commit the changes and push them to the `main` branch. This workflow is runs every time you push changes to the `main` branch. You can find more information about workflow triggers [in the GitHub documentation](https://docs.github.com/en/actions/writing-workflows/choosing-when-your-workflow-runs/events-that-trigger-workflows). - -Go to the **Actions** tab of you GitHub repository. It displays the workflow. Selecting the workflow shows you the breakdown of all the steps. - -When the workflow is complete, go to your [repositories on Docker Hub](https://hub.docker.com/repositories). If you see the new repository in that list, it means the GitHub Actions workflow successfully pushed the image to Docker Hub. - -## Summary - -In this section, you learned how to set up a GitHub Actions workflow for your Ruby on Rails application. - -Related information: - -- [Introduction to GitHub Actions](/guides/gha.md) -- [Docker Build GitHub Actions](/manuals/build/ci/github-actions/_index.md) -- [Workflow syntax for GitHub Actions](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions) - -## Next steps - -In the next section, you'll learn how you can develop your application using containers. - diff --git a/content/guides/ruby/containerize.md b/content/guides/ruby/containerize.md index 5243efd211f7..b2b34790adb7 100644 --- a/content/guides/ruby/containerize.md +++ b/content/guides/ruby/containerize.md @@ -386,7 +386,4 @@ Related information: - [Docker Compose overview](/manuals/compose/_index.md) -## Next steps - -In the next section, you'll take a look at how to set up a CI/CD pipeline using GitHub Actions. diff --git a/content/guides/ruby/deploy.md b/content/guides/ruby/deploy.md deleted file mode 100644 index 0fe06fb3bb74..000000000000 --- a/content/guides/ruby/deploy.md +++ /dev/null @@ -1,167 +0,0 @@ ---- -title: Test your Ruby on Rails deployment -linkTitle: Test your deployment -weight: 50 -keywords: deploy, kubernetes, ruby -description: Learn how to develop locally using Kubernetes -aliases: - - /language/ruby/deploy/ - - /guides/language/ruby/deploy/ ---- - -## Prerequisites - -- Complete all the previous sections of this guide, starting with [Containerize a Ruby on Rails application](containerize.md). -- [Turn on Kubernetes](/manuals/desktop/use-desktop/kubernetes.md#enable-kubernetes) in Docker Desktop. - -## Overview - -In this section, you'll learn how to use Docker Desktop to deploy your application to a fully-featured Kubernetes environment on your development machine. This lets you to test and debug your workloads on Kubernetes locally before deploying. - -## Create a Kubernetes YAML file - -In your `docker-ruby-on-rails` directory, create a file named -`docker-ruby-on-rails-kubernetes.yaml`. Open the file in an IDE or text editor and add -the following contents. Replace `DOCKER_USERNAME/REPO_NAME` with your Docker -username and the name of the repository that you created in [Configure CI/CD for -your Ruby on Rails application](configure-github-actions.md). - -```yaml -apiVersion: apps/v1 -kind: Deployment -metadata: - name: docker-ruby-on-rails-demo - namespace: default -spec: - replicas: 1 - selector: - matchLabels: - service: ruby-on-rails - template: - metadata: - labels: - service: ruby-on-rails - spec: - containers: - - name: ruby-on-rails-container - image: DOCKER_USERNAME/REPO_NAME - imagePullPolicy: Always ---- -apiVersion: v1 -kind: Service -metadata: - name: docker-ruby-on-rails-demo - namespace: default -spec: - type: NodePort - selector: - service: ruby-on-rails - ports: - - port: 3000 - targetPort: 3000 - nodePort: 30001 -``` - -In this Kubernetes YAML file, there are two objects, separated by the `---`: - -- A Deployment, describing a scalable group of identical pods. In this case, - you'll get just one replica, or copy of your pod. That pod, which is - described under `template`, has just one container in it. The - container is created from the image built by GitHub Actions in [Configure CI/CD for - your Ruby on Rails application](configure-github-actions.md). -- A NodePort service, which will route traffic from port 30001 on your host to - port 8001 inside the pods it routes to, allowing you to reach your app - from the network. - -To learn more about Kubernetes objects, see the [Kubernetes documentation](https://kubernetes.io/docs/home/). - -## Deploy and check your application - -1. In a terminal, navigate to `docker-ruby-on-rails` and deploy your application to - Kubernetes. - - ```console - $ kubectl apply -f docker-ruby-on-rails-kubernetes.yaml - ``` - - You should see output that looks like the following, indicating your Kubernetes objects were created successfully. - - ```shell - deployment.apps/docker-ruby-on-rails-demo created - service/docker-ruby-on-rails-demo created - ``` - -2. Make sure everything worked by listing your deployments. - - ```console - $ kubectl get deployments - ``` - - Your deployment should be listed as follows: - - ```shell - NAME READY UP-TO-DATE AVAILABLE AGE - docker-ruby-on-rails-demo 1/1 1 1 15s - ``` - - This indicates all one of the pods you asked for in your YAML are up and running. Do the same check for your services. - - ```console - $ kubectl get services - ``` - - You should get output like the following. - - ```shell - NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE - kubernetes ClusterIP 10.96.0.1 443/TCP 23h - docker-ruby-on-rails-demo NodePort 10.99.128.230 3000:30001/TCP 75s - ``` - - In addition to the default `kubernetes` service, you can see your `docker-ruby-on-rails-demo` service, accepting traffic on port 30001/TCP. - -3. To create and migrate the database in a Ruby on Rails application running on Kubernetes, you need to follow these steps. - - **Get the Current Pods**: - First, you need to identify the pods running in your Kubernetes cluster. Execute the following command to list the current pods in the `default` namespace: - - ```sh - # Get the current pods in the cluster in the namespace default - $ kubectl get pods - ``` - - This command will display a list of all pods in the `default` namespace. Look for the pod with the prefix `docker-ruby-on-rails-demo-`. Here is an example output: - - ```console - NAME READY STATUS RESTARTS AGE - docker-ruby-on-rails-demo-7cbddb5d6f-qh44l 1/1 Running 2 (22h ago) 9d - ``` - - **Execute the Migration Command**: - Once you've identified the correct pod, use the `kubectl exec` command to run the database migration inside the pod. - - ```sh - $ kubectl exec -it docker-ruby-on-rails-demo-7cbddb5d6f-qh44l -- rails db:migrate RAILS_ENV=development - ``` - - This command opens an interactive terminal session (`-it`) in the specified pod and runs the `rails db:migrate` command with the environment set to development (`RAILS_ENV=development`). - - By following these steps, you ensure that your database is properly migrated within the Ruby on Rails application running in your Kubernetes cluster. This process helps maintain the integrity and consistency of your application's data structure during deployment and updates. - -4. Open the browser and go to [http://localhost:30001](http://localhost:30001), you should see the ruby on rails application working. - -5. Run the following command to tear down your application. - - ```console - $ kubectl delete -f docker-ruby-on-rails-kubernetes.yaml - ``` - -## Summary - -In this section, you learned how to use Docker Desktop to deploy your application to a fully-featured Kubernetes environment on your development machine. - -Related information: - -- [Kubernetes documentation](https://kubernetes.io/docs/home/) -- [Deploy on Kubernetes with Docker Desktop](/manuals/desktop/use-desktop/kubernetes.md) -- [Swarm mode overview](/manuals/engine/swarm/_index.md) diff --git a/content/guides/ruby/develop.md b/content/guides/ruby/develop.md index 2f2d738b5495..408562079def 100644 --- a/content/guides/ruby/develop.md +++ b/content/guides/ruby/develop.md @@ -198,6 +198,3 @@ Related information: - [Compose file watch](/manuals/compose/how-tos/file-watch.md) - [Multi-stage builds](/manuals/build/building/multi-stage.md) -## Next steps - -In the next section, you'll learn how you can locally test and debug your workloads on Kubernetes before deploying. diff --git a/content/guides/rust/_index.md b/content/guides/rust/_index.md index 483040adbfce..ed3eee55af98 100644 --- a/content/guides/rust/_index.md +++ b/content/guides/rust/_index.md @@ -23,8 +23,6 @@ The Rust language-specific guide teaches you how to create a containerized Rust - Set up volumes and networking - Orchestrate containers using Compose - Use containers for development -- Configure a CI/CD pipeline for your application using GitHub Actions -- Deploy your containerized Rust application locally to Kubernetes to test and debug your deployment After completing the Rust modules, you should be able to containerize your own Rust application based on the examples and instructions provided in this guide. diff --git a/content/guides/rust/configure-ci-cd.md b/content/guides/rust/configure-ci-cd.md deleted file mode 100644 index 80a6f287c715..000000000000 --- a/content/guides/rust/configure-ci-cd.md +++ /dev/null @@ -1,132 +0,0 @@ ---- -title: Configure CI/CD for your Rust application -linkTitle: Configure CI/CD -weight: 40 -keywords: rust, CI/CD, local, development -description: Learn how to Configure CI/CD for your application -aliases: - - /language/rust/configure-ci-cd/ - - /guides/language/rust/configure-ci-cd/ ---- - -## Prerequisites - -Complete the previous sections of this guide, starting with [Develop your Rust application](develop.md). You must have a [GitHub](https://github.com/signup) account and a verified [Docker](https://hub.docker.com/signup) account to complete this section. - -## Overview - -In this section, you'll learn how to set up and use GitHub Actions to build and push your Docker image to Docker Hub. You will complete the following steps: - -1. Create a new repository on GitHub. -2. Define the GitHub Actions workflow. -3. Run the workflow. - -## Step one: Create the repository - -Create a GitHub repository, configure the Docker Hub credentials, and push your source code. - -1. [Create a new repository](https://github.com/new) on GitHub. - -2. Open the repository **Settings**, and go to **Secrets and variables** > - **Actions**. - -3. Create a new **Repository variable** named `DOCKER_USERNAME` and your Docker ID as a value. - -4. Create a new [Personal Access Token (PAT)](/manuals/security/access-tokens.md#create-an-access-token) for Docker Hub. You can name this token `docker-tutorial`. Make sure access permissions include Read and Write. - -5. Add the PAT as a **Repository secret** in your GitHub repository, with the name - `DOCKERHUB_TOKEN`. - -6. In your local repository on your machine, run the following command to change - the origin to the repository you just created. Make sure you change - `your-username` to your GitHub username and `your-repository` to the name of - the repository you created. - - ```console - $ git remote set-url origin https://github.com/your-username/your-repository.git - ``` - -7. Run the following commands to stage, commit, and push your local repository to GitHub. - - ```console - $ git add -A - $ git commit -m "my commit" - $ git push -u origin main - ``` - -## Step two: Set up the workflow - -Set up your GitHub Actions workflow for building, testing, and pushing the image -to Docker Hub. - -1. Go to your repository on GitHub and then select the **Actions** tab. - -2. Select **set up a workflow yourself**. - - This takes you to a page for creating a new GitHub actions workflow file in - your repository, under `.github/workflows/main.yml` by default. - -3. In the editor window, copy and paste the following YAML configuration. - - ```yaml - name: ci - - on: - push: - branches: - - main - - jobs: - build: - runs-on: ubuntu-latest - steps: - - name: Login to Docker Hub - uses: docker/login-action@{{% param "login_action_version" %}} - with: - username: ${{ vars.DOCKER_USERNAME }} - password: ${{ secrets.DOCKERHUB_TOKEN }} - - - name: Set up Docker Buildx - uses: docker/setup-buildx-action@{{% param "setup_buildx_action_version" %}} - - - name: Build and push - uses: docker/build-push-action@{{% param "build_push_action_version" %}} - with: - push: true - tags: ${{ vars.DOCKER_USERNAME }}/${{ github.event.repository.name }}:latest - ``` - - For more information about the YAML syntax for `docker/build-push-action`, - refer to the [GitHub Action README](https://github.com/docker/build-push-action/blob/master/README.md). - -## Step three: Run the workflow - -Save the workflow file and run the job. - -1. Select **Commit changes...** and push the changes to the `main` branch. - - After pushing the commit, the workflow starts automatically. - -2. Go to the **Actions** tab. It displays the workflow. - - Selecting the workflow shows you the breakdown of all the steps. - -3. When the workflow is complete, go to your - [repositories on Docker Hub](https://hub.docker.com/repositories). - - If you see the new repository in that list, it means the GitHub Actions - successfully pushed the image to Docker Hub. - -## Summary - -In this section, you learned how to set up a GitHub Actions workflow for your Rust application. - -Related information: - -- [Introduction to GitHub Actions](/guides/gha.md) -- [Docker Build GitHub Actions](/manuals/build/ci/github-actions/_index.md) -- [Workflow syntax for GitHub Actions](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions) - -## Next steps - -Next, learn how you can locally test and debug your workloads on Kubernetes before deploying. diff --git a/content/guides/rust/deploy.md b/content/guides/rust/deploy.md deleted file mode 100644 index a43551f673c6..000000000000 --- a/content/guides/rust/deploy.md +++ /dev/null @@ -1,238 +0,0 @@ ---- -title: Test your Rust deployment -linkTitle: Test your deployment -weight: 50 -keywords: deploy, kubernetes, rust -description: Learn how to test your Rust deployment locally using Kubernetes -aliases: - - /language/rust/deploy/ - - /guides/language/rust/deploy/ ---- - -## Prerequisites - -- Complete the previous sections of this guide, starting with [Develop your Rust application](develop.md). -- [Turn on Kubernetes](/manuals/desktop/use-desktop/kubernetes.md#enable-kubernetes) in Docker Desktop. - -## Overview - -In this section, you'll learn how to use Docker Desktop to deploy your application to a fully-featured Kubernetes environment on your development machine. This lets you to test and debug your workloads on Kubernetes locally before deploying. - -## Create a Kubernetes YAML file - -In your `docker-rust-postgres` directory, create a file named -`docker-rust-kubernetes.yaml`. Open the file in an IDE or text editor and add -the following contents. Replace `DOCKER_USERNAME/REPO_NAME` with your Docker -username and the name of the repository that you created in [Configure CI/CD for -your Rust application](configure-ci-cd.md). - -```yaml -apiVersion: apps/v1 -kind: Deployment -metadata: - labels: - service: server - name: server - namespace: default -spec: - replicas: 1 - selector: - matchLabels: - service: server - strategy: {} - template: - metadata: - labels: - service: server - spec: - initContainers: - - name: wait-for-db - image: busybox:1.28 - command: - [ - "sh", - "-c", - 'until nc -zv db 5432; do echo "waiting for db"; sleep 2; done;', - ] - containers: - - image: DOCKER_USERNAME/REPO_NAME - name: server - imagePullPolicy: Always - ports: - - containerPort: 8000 - hostPort: 5000 - protocol: TCP - env: - - name: ADDRESS - value: 0.0.0.0:8000 - - name: PG_DBNAME - value: example - - name: PG_HOST - value: db - - name: PG_PASSWORD - value: mysecretpassword - - name: PG_USER - value: postgres - - name: RUST_LOG - value: debug - resources: {} - restartPolicy: Always -status: {} ---- -apiVersion: apps/v1 -kind: Deployment -metadata: - labels: - service: db - name: db - namespace: default -spec: - replicas: 1 - selector: - matchLabels: - service: db - strategy: - type: Recreate - template: - metadata: - labels: - service: db - spec: - containers: - - env: - - name: POSTGRES_DB - value: example - - name: POSTGRES_PASSWORD - value: mysecretpassword - - name: POSTGRES_USER - value: postgres - image: postgres:18 - name: db - ports: - - containerPort: 5432 - protocol: TCP - resources: {} - restartPolicy: Always -status: {} ---- -apiVersion: v1 -kind: Service -metadata: - labels: - service: server - name: server - namespace: default -spec: - type: NodePort - ports: - - name: "5000" - port: 5000 - targetPort: 8000 - nodePort: 30001 - selector: - service: server -status: - loadBalancer: {} ---- -apiVersion: v1 -kind: Service -metadata: - labels: - service: db - name: db - namespace: default -spec: - ports: - - name: "5432" - port: 5432 - targetPort: 5432 - selector: - service: db -status: - loadBalancer: {} -``` - -In this Kubernetes YAML file, there are four objects, separated by the `---`. In addition to a Service and Deployment for the database, the other two objects are: - -- A Deployment, describing a scalable group of identical pods. In this case, - you'll get just one replica, or copy of your pod. That pod, which is - described under `template`, has just one container in it. The container is - created from the image built by GitHub Actions in [Configure CI/CD for your - Rust application](configure-ci-cd.md). -- A NodePort service, which will route traffic from port 30001 on your host to - port 5000 inside the pods it routes to, allowing you to reach your app - from the network. - -To learn more about Kubernetes objects, see the [Kubernetes documentation](https://kubernetes.io/docs/home/). - -## Deploy and check your application - -1. In a terminal, navigate to `docker-rust-postgres` and deploy your application - to Kubernetes. - - ```console - $ kubectl apply -f docker-rust-kubernetes.yaml - ``` - - You should see output that looks like the following, indicating your Kubernetes objects were created successfully. - - ```shell - deployment.apps/server created - deployment.apps/db created - service/server created - service/db created - ``` - -2. Make sure everything worked by listing your deployments. - - ```console - $ kubectl get deployments - ``` - - Your deployment should be listed as follows: - - ```shell - NAME READY UP-TO-DATE AVAILABLE AGE - db 1/1 1 1 2m21s - server 1/1 1 1 2m21s - ``` - - This indicates all of the pods you asked for in your YAML are up and running. Do the same check for your services. - - ```console - $ kubectl get services - ``` - - You should get output like the following. - - ```shell - NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE - db ClusterIP 10.105.167.81 5432/TCP 109s - kubernetes ClusterIP 10.96.0.1 443/TCP 9d - server NodePort 10.101.235.213 5000:30001/TCP 109s - ``` - - In addition to the default `kubernetes` service, you can see your `service-entrypoint` service, accepting traffic on port 30001/TCP. - -3. In a terminal, curl the service. - - ```console - $ curl http://localhost:30001/users - [{"id":1,"login":"root"}] - ``` - -4. Run the following command to tear down your application. - - ```console - $ kubectl delete -f docker-rust-kubernetes.yaml - ``` - -## Summary - -In this section, you learned how to use Docker Desktop to deploy your application to a fully-featured Kubernetes environment on your development machine. - -Related information: - -- [Kubernetes documentation](https://kubernetes.io/docs/home/) -- [Deploy on Kubernetes with Docker Desktop](/manuals/desktop/use-desktop/kubernetes.md) -- [Swarm mode overview](/manuals/engine/swarm/_index.md) diff --git a/content/guides/rust/develop.md b/content/guides/rust/develop.md index b3cbdf0198ec..b70e478511f0 100644 --- a/content/guides/rust/develop.md +++ b/content/guides/rust/develop.md @@ -298,6 +298,3 @@ Related information: - [Docker volumes](/manuals/engine/storage/volumes.md) - [Compose overview](/manuals/compose/_index.md) -## Next steps - -In the next section, you'll take a look at how to set up a CI/CD pipeline using GitHub Actions. diff --git a/content/guides/vuejs/_index.md b/content/guides/vuejs/_index.md index 8bd306da6c4b..645d57b66b11 100644 --- a/content/guides/vuejs/_index.md +++ b/content/guides/vuejs/_index.md @@ -33,10 +33,7 @@ In this guide, you will learn how to: - Containerize and run an Vue.js application using Docker. - Set up a local development environment for Vue.js inside a container. - Run tests for your Vue.js application within a Docker container. -- Configure a CI/CD pipeline using GitHub Actions for your containerized app. -- Deploy the containerized Vue.js application to a local Kubernetes cluster for testing and debugging. - -You'll start by containerizing an existing Vue.js application and work your way up to production-level deployments. +You'll start by containerizing an existing Vue.js application. --- diff --git a/content/guides/vuejs/configure-github-actions.md b/content/guides/vuejs/configure-github-actions.md deleted file mode 100644 index 1fb6704f0784..000000000000 --- a/content/guides/vuejs/configure-github-actions.md +++ /dev/null @@ -1,320 +0,0 @@ ---- -title: Automate your builds with GitHub Actions -linkTitle: GitHub Actions CI -weight: 60 -keywords: CI/CD, GitHub( Actions), Vue.js -description: Learn how to configure CI/CD using GitHub Actions for your Vue.js application. - ---- - -## Prerequisites - -Complete all the previous sections of this guide, starting with [Containerize an Vue.js application](containerize.md). - -You must also have: -- A [GitHub](https://github.com/signup) account. -- A verified [Docker Hub](https://hub.docker.com/signup) account. - ---- - -## Overview - -In this section, you'll set up a CI/CD pipeline using [GitHub Actions](https://docs.github.com/en/actions) to automatically: - -- Build your Vue.js application inside a Docker container. -- Run tests in a consistent environment. -- Push the production-ready image to [Docker Hub](https://hub.docker.com). - ---- - -## Connect your GitHub repository to Docker Hub - -To enable GitHub Actions to build and push Docker images, you’ll securely store your Docker Hub credentials in your new GitHub repository. - -### Step 1: Generate Docker Hub credentials and set GitHub secrets - -1. Create a Personal Access Token (PAT) from [Docker Hub](https://hub.docker.com) - 1. Go to your **Docker Hub account → Account Settings → Security**. - 2. Generate a new Access Token with **Read/Write** permissions. - 3. Name it something like `docker-vuejs-sample`. - 4. Copy and save the token — you’ll need it in Step 4. - -2. Create a repository in [Docker Hub](https://hub.docker.com/repositories/) - 1. Go to your **Docker Hub account → Create a repository**. - 2. For the Repository Name, use something descriptive — for example: `vuejs-sample`. - 3. Once created, copy and save the repository name — you’ll need it in Step 4. - -3. Create a new [GitHub repository](https://github.com/new) for your Vue.js project - -4. Add Docker Hub credentials as GitHub repository secrets - - In your newly created GitHub repository: - - 1. Navigate to: - **Settings → Secrets and variables → Actions → New repository secret**. - - 2. Add the following secrets: - - | Name | Value | - |-------------------|--------------------------------| - | `DOCKER_USERNAME` | Your Docker Hub username | - | `DOCKERHUB_TOKEN` | Your Docker Hub access token (created in Step 1) | - | `DOCKERHUB_PROJECT_NAME` | Your Docker Project Name (created in Step 2) | - - These secrets allow GitHub Actions to authenticate securely with Docker Hub during automated workflows. - -5. Connect Your Local Project to GitHub - - Link your local project `docker-vuejs-sample` to the GitHub repository you just created by running the following command from your project root: - - ```console - $ git remote set-url origin https://github.com/{your-username}/{your-repository-name}.git - ``` - - >[!IMPORTANT] - >Replace `{your-username}` and `{your-repository}` with your actual GitHub username and repository name. - - To confirm that your local project is correctly connected to the remote GitHub repository, run: - - ```console - $ git remote -v - ``` - - You should see output similar to: - - ```console - origin https://github.com/{your-username}/{your-repository-name}.git (fetch) - origin https://github.com/{your-username}/{your-repository-name}.git (push) - ``` - - This confirms that your local repository is properly linked and ready to push your source code to GitHub. - -6. Push your source code to GitHub - - Follow these steps to commit and push your local project to your GitHub repository: - - 1. Stage all files for commit. - - ```console - $ git add -A - ``` - This command stages all changes — including new, modified, and deleted files — preparing them for commit. - - - 2. Commit the staged changes with a descriptive message. - - ```console - $ git commit -m "Initial commit" - ``` - This command creates a commit that snapshots the staged changes with a descriptive message. - - 3. Push the code to the `main` branch. - - ```console - $ git push -u origin main - ``` - This command pushes your local commits to the `main` branch of the remote GitHub repository and sets the upstream branch. - -Once completed, your code will be available on GitHub, and any GitHub Actions workflow you’ve configured will run automatically. - -> [!NOTE] -> Learn more about the Git commands used in this step: -> - [Git add](https://git-scm.com/docs/git-add) – Stage changes (new, modified, deleted) for commit -> - [Git commit](https://git-scm.com/docs/git-commit) – Save a snapshot of your staged changes -> - [Git push](https://git-scm.com/docs/git-push) – Upload local commits to your GitHub repository -> - [Git remote](https://git-scm.com/docs/git-remote) – View and manage remote repository URLs - ---- - -### Step 2: Set up the workflow - -Now you'll create a GitHub Actions workflow that builds your Docker image, runs tests, and pushes the image to Docker Hub. - -1. Go to your repository on GitHub and select the **Actions** tab in the top menu. - -2. Select **Set up a workflow yourself** when prompted. - - This opens an inline editor to create a new workflow file. By default, it will be saved to: - `.github/workflows/main.yml` - - -3. Add the following workflow configuration to the new file: - -```yaml -name: CI/CD – Vue.js App with Docker - -on: - push: - branches: [main] - pull_request: - branches: [main] - types: [opened, synchronize, reopened] - -jobs: - build-test-deploy: - name: Build, Test & Deploy - runs-on: ubuntu-latest - - steps: - # 1. Checkout the codebase - - name: Checkout Code - uses: actions/checkout@{{% param "checkout_action_version" %}} - with: - fetch-depth: 0 - - # 2. Set up Docker Buildx - - name: Set up Docker Buildx - uses: docker/setup-buildx-action@{{% param "setup_buildx_action_version" %}} - - # 3. Cache Docker layers - - name: Cache Docker Layers - uses: actions/cache@{{% param "cache_action_version" %}} - with: - path: /tmp/.buildx-cache - key: ${{ runner.os }}-buildx-${{ github.sha }} - restore-keys: | - ${{ runner.os }}-buildx- - - # 4. Cache npm dependencies - - name: Cache npm Dependencies - uses: actions/cache@{{% param "cache_action_version" %}} - with: - path: ~/.npm - key: ${{ runner.os }}-npm-${{ hashFiles('**/package-lock.json') }} - restore-keys: | - ${{ runner.os }}-npm- - - # 5. Generate build metadata - - name: Generate Build Metadata - id: meta - run: | - echo "REPO_NAME=${GITHUB_REPOSITORY##*/}" >> "$GITHUB_OUTPUT" - echo "SHORT_SHA=${GITHUB_SHA::7}" >> "$GITHUB_OUTPUT" - - # 6. Build Docker image for testing - - name: Build Dev Docker Image - uses: docker/build-push-action@{{% param "build_push_action_version" %}} - with: - context: . - file: Dockerfile.dev - tags: ${{ steps.meta.outputs.REPO_NAME }}-dev:latest - load: true - cache-from: type=local,src=/tmp/.buildx-cache - cache-to: type=local,dest=/tmp/.buildx-cache,mode=max - - # 7. Run unit tests inside container - - name: Run Vue.js Tests - run: | - docker run --rm \ - --workdir /app \ - --entrypoint "" \ - ${{ steps.meta.outputs.REPO_NAME }}-dev:latest \ - sh -c "npm ci && npm run test -- --ci --runInBand" - env: - CI: true - NODE_ENV: test - timeout-minutes: 10 - - # 8. Log in to Docker Hub - - name: Docker Hub Login - uses: docker/login-action@{{% param "login_action_version" %}} - with: - username: ${{ secrets.DOCKER_USERNAME }} - password: ${{ secrets.DOCKERHUB_TOKEN }} - - # 9. Build and push production image - - name: Build and Push Production Image - uses: docker/build-push-action@{{% param "build_push_action_version" %}} - with: - context: . - file: Dockerfile - push: true - platforms: linux/amd64,linux/arm64 - tags: | - ${{ secrets.DOCKER_USERNAME }}/${{ secrets.DOCKERHUB_PROJECT_NAME }}:latest - ${{ secrets.DOCKER_USERNAME }}/${{ secrets.DOCKERHUB_PROJECT_NAME }}:${{ steps.meta.outputs.SHORT_SHA }} - cache-from: type=local,src=/tmp/.buildx-cache -``` - -This workflow performs the following tasks for your Vue.js application: -- Triggers on every `push` or `pull request` targeting the `main` branch. -- Builds a development Docker image using `Dockerfile.dev`, optimized for testing. -- Executes unit tests using Vitest inside a clean, containerized environment to ensure consistency. -- Halts the workflow immediately if any test fails — enforcing code quality. -- Caches both Docker build layers and npm dependencies for faster CI runs. -- Authenticates securely with Docker Hub using GitHub repository secrets. -- Builds a production-ready image using the `prod` stage in `Dockerfile`. -- Tags and pushes the final image to Docker Hub with both `latest` and short SHA tags for traceability. - -> [!NOTE] -> For more information about `docker/build-push-action`, refer to the [GitHub Action README](https://github.com/docker/build-push-action/blob/master/README.md). - ---- - -### Step 3: Run the workflow - -After you've added your workflow file, it's time to trigger and observe the CI/CD process in action. - -1. Commit and push your workflow file - - Select "Commit changes…" in the GitHub editor. - - This push will automatically trigger the GitHub Actions pipeline. - -2. Monitor the workflow execution - - Go to the Actions tab in your GitHub repository. - - Click into the workflow run to follow each step: **build**, **test**, and (if successful) **push**. - -3. Verify the Docker image on Docker Hub - - - After a successful workflow run, visit your [Docker Hub repositories](https://hub.docker.com/repositories). - - You should see a new image under your repository with: - - Repository name: `${your-repository-name}` - - Tags include: - - `latest` – represents the most recent successful build; ideal for quick testing or deployment. - - `` – a unique identifier based on the commit hash, useful for version tracking, rollbacks, and traceability. - -> [!TIP] Protect your main branch -> To maintain code quality and prevent accidental direct pushes, enable branch protection rules: -> - Navigate to your **GitHub repo → Settings → Branches**. -> - Under Branch protection rules, click **Add rule**. -> - Specify `main` as the branch name. -> - Enable options like: -> - *Require a pull request before merging*. -> - *Require status checks to pass before merging*. -> -> This ensures that only tested and reviewed code is merged into `main` branch. ---- - -## Summary - -In this section, you set up a complete CI/CD pipeline for your containerized Vue.js application using GitHub Actions. - -Here's what you accomplished: - -- Created a new GitHub repository specifically for your project. -- Generated a secure Docker Hub access token and added it to GitHub as a secret. -- Defined a GitHub Actions workflow that: - - Build your application inside a Docker container. - - Run tests in a consistent, containerized environment. - - Push a production-ready image to Docker Hub if tests pass. -- Triggered and verified the workflow execution through GitHub Actions. -- Confirmed that your image was successfully published to Docker Hub. - -With this setup, your Vue.js application is now ready for automated testing and deployment across environments — increasing confidence, consistency, and team productivity. - ---- - -## Related resources - -Deepen your understanding of automation and best practices for containerized apps: - -- [Introduction to GitHub Actions](/guides/gha.md) – Learn how GitHub Actions automate your workflows -- [Docker Build GitHub Actions](/manuals/build/ci/github-actions/_index.md) – Set up container builds with GitHub Actions -- [Workflow syntax for GitHub Actions](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions) – Full reference for writing GitHub workflows -- [Compose file reference](/compose/compose-file/) – Full configuration reference for `compose.yaml` -- [Best practices for writing Dockerfiles](/develop/develop-images/dockerfile_best-practices/) – Optimize your image for performance and security - ---- - -## Next steps - -Next, learn how you can locally test and debug your Vue.js workloads on Kubernetes before deploying. This helps you ensure your application behaves as expected in a production-like environment, reducing surprises during deployment. diff --git a/content/guides/vuejs/deploy.md b/content/guides/vuejs/deploy.md deleted file mode 100644 index 678f8956e055..000000000000 --- a/content/guides/vuejs/deploy.md +++ /dev/null @@ -1,201 +0,0 @@ ---- -title: Test your Vue.js deployment -linkTitle: Test your deployment -weight: 60 -keywords: deploy, kubernetes, vue, vue.js -description: Learn how to deploy locally to test and debug your Kubernetes deployment - ---- - -## Prerequisites - -Before you begin, make sure you’ve completed the following: -- Complete all the previous sections of this guide, starting with [Containerize Vue.js application](containerize.md). -- [Enable Kubernetes](/manuals/desktop/use-desktop/kubernetes.md#enable-kubernetes) in Docker Desktop. - -> **New to Kubernetes?** -> Visit the [Kubernetes basics tutorial](https://kubernetes.io/docs/tutorials/kubernetes-basics/) to get familiar with how clusters, pods, deployments, and services work. - ---- - -## Overview - -This section guides you through deploying your containerized Vue.js application locally using [Docker Desktop’s built-in Kubernetes](/desktop/kubernetes/). Running your app in a local Kubernetes cluster closely simulates a real production environment, enabling you to test, validate, and debug your workloads with confidence before promoting them to staging or production. - ---- - -## Create a Kubernetes YAML file - -Follow these steps to define your deployment configuration: - -1. In the root of your project, create a new file named: vuejs-sample-kubernetes.yaml - -2. Open the file in your IDE or preferred text editor. - -3. Add the following configuration, and be sure to replace `{DOCKER_USERNAME}` and `{DOCKERHUB_PROJECT_NAME}` with your actual Docker Hub username and repository name from the previous [Automate your builds with GitHub Actions](configure-github-actions.md). - - -```yaml -apiVersion: apps/v1 -kind: Deployment -metadata: - name: vuejs-sample - namespace: default -spec: - replicas: 1 - selector: - matchLabels: - app: vuejs-sample - template: - metadata: - labels: - app: vuejs-sample - spec: - containers: - - name: vuejs-container - image: {DOCKER_USERNAME}/{DOCKERHUB_PROJECT_NAME}:latest - imagePullPolicy: Always - ports: - - containerPort: 8080 - resources: - limits: - cpu: "500m" - memory: "256Mi" - requests: - cpu: "250m" - memory: "128Mi" ---- -apiVersion: v1 -kind: Service -metadata: - name: vuejs-sample-service - namespace: default -spec: - type: NodePort - selector: - app: vuejs-sample - ports: - - port: 8080 - targetPort: 8080 - nodePort: 30001 -``` - -This manifest defines two key Kubernetes resources, separated by `---`: - -- Deployment - Deploys a single replica of your Vue.js application inside a pod. The pod uses the Docker image built and pushed by your GitHub Actions CI/CD workflow - (refer to [Automate your builds with GitHub Actions](configure-github-actions.md)). - The container listens on port `8080`, which is typically used by [Nginx](https://nginx.org/en/docs/) to serve your production Vue.js app. - -- Service (NodePort) - Exposes the deployed pod to your local machine. - It forwards traffic from port `30001` on your host to port `8080` inside the container. - This lets you access the application in your browser at [http://localhost:30001](http://localhost:30001). - -> [!NOTE] -> To learn more about Kubernetes objects, see the [Kubernetes documentation](https://kubernetes.io/docs/home/). - ---- - -## Deploy and check your application - -Follow these steps to deploy your containerized Vue.js app into a local Kubernetes cluster and verify that it’s running correctly. - -### Step 1. Apply the Kubernetes configuration - -In your terminal, navigate to the directory where your `vuejs-sample-kubernetes.yaml` file is located, then deploy the resources using: - -```console - $ kubectl apply -f vuejs-sample-kubernetes.yaml -``` - -If everything is configured properly, you’ll see confirmation that both the Deployment and the Service were created: - -```shell - deployment.apps/vuejs-sample created - service/vuejs-sample-service created -``` - -This confirms that both the Deployment and the Service were successfully created and are now running inside your local cluster. - -### Step 2. Check the deployment status - -Run the following command to check the status of your deployment: - -```console - $ kubectl get deployments -``` - -You should see output similar to the following: - -```shell - NAME READY UP-TO-DATE AVAILABLE AGE - vuejs-sample 1/1 1 1 1m14s -``` - -This confirms that your pod is up and running with one replica available. - -### Step 3. Verify the service exposure - -Check if the NodePort service is exposing your app to your local machine: - -```console -$ kubectl get services -``` - -You should see something like: - -```shell -NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE -vuejs-sample-service NodePort 10.98.233.59 8080:30001/TCP 1m -``` - -This output confirms that your app is available via NodePort on port 30001. - -### Step 4. Access your app in the browser - -Open your browser and navigate to [http://localhost:30001](http://localhost:30001). - -You should see your production-ready Vue.js Sample application running — served by your local Kubernetes cluster. - -### Step 5. Clean up Kubernetes resources - -Once you're done testing, you can delete the deployment and service using: - -```console - $ kubectl delete -f vuejs-sample-kubernetes.yaml -``` - -Expected output: - -```shell - deployment.apps "vuejs-sample" deleted - service "vuejs-sample-service" deleted -``` - -This ensures your cluster stays clean and ready for the next deployment. - ---- - -## Summary - -In this section, you learned how to deploy your Vue.js application to a local Kubernetes cluster using Docker Desktop. This setup allows you to test and debug your containerized app in a production-like environment before deploying it to the cloud. - -What you accomplished: - -- Created a Kubernetes Deployment and NodePort Service for your Vue.js app -- Used `kubectl apply` to deploy the application locally -- Verified the app was running and accessible at `http://localhost:30001` -- Cleaned up your Kubernetes resources after testing - ---- - -## Related resources - -Explore official references and best practices to sharpen your Kubernetes deployment workflow: - -- [Kubernetes documentation](https://kubernetes.io/docs/home/) – Learn about core concepts, workloads, services, and more. -- [Deploy on Kubernetes with Docker Desktop](/manuals) – Use Docker Desktop’s built-in Kubernetes support for local testing and development. -- [`kubectl` CLI reference](https://kubernetes.io/docs/reference/kubectl/) – Manage Kubernetes clusters from the command line. -- [Kubernetes Deployment resource](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/) – Understand how to manage and scale applications using Deployments. -- [Kubernetes Service resource](https://kubernetes.io/docs/concepts/services-networking/service/) – Learn how to expose your application to internal and external traffic. \ No newline at end of file diff --git a/content/guides/vuejs/run-tests.md b/content/guides/vuejs/run-tests.md index 7e1f2d76897e..2c932d581e80 100644 --- a/content/guides/vuejs/run-tests.md +++ b/content/guides/vuejs/run-tests.md @@ -133,6 +133,3 @@ Explore official references and best practices to sharpen your Docker testing wo - [`docker compose run` CLI reference](/reference/cli/docker/compose/run/) – Run one-off commands in a service container. --- -## Next steps - -Next, you’ll learn how to set up a CI/CD pipeline using GitHub Actions to automatically build and test your Vue.js application in a containerized environment. This ensures your code is validated on every push or pull request, maintaining consistency and reliability across your development workflow. From ca033e37063526f5eafb64b517a699bcce7d4536 Mon Sep 17 00:00:00 2001 From: Craig Osterhout Date: Wed, 17 Jun 2026 13:48:51 -0700 Subject: [PATCH 2/2] add aliases Signed-off-by: Craig Osterhout --- content/guides/angular/_index.md | 3 +++ content/guides/bun/_index.md | 3 +++ content/guides/cpp/_index.md | 7 +++++++ content/guides/deno/_index.md | 3 +++ content/guides/dotnet/_index.md | 6 ++++++ content/guides/golang/_index.md | 6 ++++++ content/guides/java/_index.md | 6 ++++++ content/guides/nextjs/_index.md | 3 +++ content/guides/nodejs/_index.md | 7 +++++++ content/guides/php/_index.md | 6 ++++++ content/guides/python/_index.md | 8 ++++++++ content/guides/r/_index.md | 6 ++++++ content/guides/reactjs/_index.md | 3 +++ content/guides/ruby/_index.md | 7 +++++++ content/guides/rust/_index.md | 6 ++++++ content/guides/vuejs/_index.md | 2 ++ 16 files changed, 82 insertions(+) diff --git a/content/guides/angular/_index.md b/content/guides/angular/_index.md index 3cfe4e32b646..031143341b0e 100644 --- a/content/guides/angular/_index.md +++ b/content/guides/angular/_index.md @@ -7,6 +7,9 @@ summary: | This guide explains how to containerize Angular applications using Docker. toc_min: 1 toc_max: 2 +aliases: + - /guides/angular/configure-github-actions/ + - /guides/angular/deploy/ languages: [js] params: time: 20 minutes diff --git a/content/guides/bun/_index.md b/content/guides/bun/_index.md index d05a1139ca05..a8a2be5b6a7d 100644 --- a/content/guides/bun/_index.md +++ b/content/guides/bun/_index.md @@ -5,6 +5,9 @@ title: Bun language-specific guide summary: | Learn how to containerize JavaScript applications with the Bun runtime. linkTitle: Bun +aliases: + - /guides/bun/configure-ci-cd/ + - /guides/bun/deploy/ languages: [js] tags: [dhi] params: diff --git a/content/guides/cpp/_index.md b/content/guides/cpp/_index.md index afcd012247de..073680c6d0d1 100644 --- a/content/guides/cpp/_index.md +++ b/content/guides/cpp/_index.md @@ -10,6 +10,13 @@ toc_max: 2 aliases: - /language/cpp/ - /guides/language/cpp/ + - /guides/cpp/configure-ci-cd/ + - /language/cpp/configure-ci-cd/ + - /guides/language/cpp/configure-ci-cd/ + - /guides/cpp/deploy/ + - /language/cpp/deploy/ + - /guides/language/cpp/deploy/ + - /guides/cpp/security/ languages: [cpp] params: time: 20 minutes diff --git a/content/guides/deno/_index.md b/content/guides/deno/_index.md index 05fca9568f96..9f6ab35195d8 100644 --- a/content/guides/deno/_index.md +++ b/content/guides/deno/_index.md @@ -5,6 +5,9 @@ title: Deno language-specific guide summary: | Learn how to containerize JavaScript applications with the Deno runtime using Docker. linkTitle: Deno +aliases: + - /guides/deno/configure-ci-cd/ + - /guides/deno/deploy/ languages: [js] tags: [dhi] params: diff --git a/content/guides/dotnet/_index.md b/content/guides/dotnet/_index.md index ebc4245469fc..11d6058b2ae5 100644 --- a/content/guides/dotnet/_index.md +++ b/content/guides/dotnet/_index.md @@ -8,6 +8,12 @@ keywords: getting started, .net aliases: - /language/dotnet/ - /guides/language/dotnet/ + - /guides/dotnet/configure-ci-cd/ + - /language/dotnet/configure-ci-cd/ + - /guides/language/dotnet/configure-ci-cd/ + - /guides/dotnet/deploy/ + - /language/dotnet/deploy/ + - /guides/language/dotnet/deploy/ languages: [c-sharp] params: time: 20 minutes diff --git a/content/guides/golang/_index.md b/content/guides/golang/_index.md index c95c992d7444..ad093ceb18ff 100644 --- a/content/guides/golang/_index.md +++ b/content/guides/golang/_index.md @@ -10,6 +10,12 @@ toc_max: 2 aliases: - /language/golang/ - /guides/language/golang/ + - /guides/golang/configure-ci-cd/ + - /language/golang/configure-ci-cd/ + - /guides/language/golang/configure-ci-cd/ + - /guides/golang/deploy/ + - /language/golang/deploy/ + - /guides/language/golang/deploy/ languages: [go] params: time: 30 minutes diff --git a/content/guides/java/_index.md b/content/guides/java/_index.md index 748576a56c7f..96b2c04a77db 100644 --- a/content/guides/java/_index.md +++ b/content/guides/java/_index.md @@ -10,6 +10,12 @@ toc_max: 2 aliases: - /language/java/ - /guides/language/java/ + - /guides/java/configure-ci-cd/ + - /language/java/configure-ci-cd/ + - /guides/language/java/configure-ci-cd/ + - /guides/java/deploy/ + - /language/java/deploy/ + - /guides/language/java/deploy/ languages: [java] params: time: 20 minutes diff --git a/content/guides/nextjs/_index.md b/content/guides/nextjs/_index.md index c75d3b806760..0a7c772c55e5 100644 --- a/content/guides/nextjs/_index.md +++ b/content/guides/nextjs/_index.md @@ -8,6 +8,9 @@ summary: | development and testing in containers. toc_min: 1 toc_max: 2 +aliases: + - /guides/nextjs/configure-github-actions/ + - /guides/nextjs/deploy/ languages: [js] tags: [frameworks] params: diff --git a/content/guides/nodejs/_index.md b/content/guides/nodejs/_index.md index af477e1d63c5..68670ef4121b 100644 --- a/content/guides/nodejs/_index.md +++ b/content/guides/nodejs/_index.md @@ -10,6 +10,13 @@ toc_max: 2 aliases: - /language/nodejs/ - /guides/language/nodejs/ + - /guides/nodejs/configure-github-actions/ + - /language/nodejs/configure-ci-cd/ + - /guides/language/nodejs/configure-ci-cd/ + - /guides/nodejs/deploy/ + - /language/nodejs/deploy/ + - /guides/language/nodejs/deploy/ + - /guides/nodejs/secure-supply-chain/ languages: [js] tags: [dhi] params: diff --git a/content/guides/php/_index.md b/content/guides/php/_index.md index 1fe5f46142d8..f242a10cbb02 100644 --- a/content/guides/php/_index.md +++ b/content/guides/php/_index.md @@ -10,6 +10,12 @@ toc_max: 2 aliases: - /language/php/ - /guides/language/php/ + - /guides/php/configure-ci-cd/ + - /language/php/configure-ci-cd/ + - /guides/language/php/configure-ci-cd/ + - /guides/php/deploy/ + - /language/php/deploy/ + - /guides/language/php/deploy/ languages: [php] params: time: 20 minutes diff --git a/content/guides/python/_index.md b/content/guides/python/_index.md index 2afeabfbf0ff..806836ac3d2a 100644 --- a/content/guides/python/_index.md +++ b/content/guides/python/_index.md @@ -10,6 +10,14 @@ toc_max: 2 aliases: - /language/python/ - /guides/language/python/ + - /guides/python/configure-github-actions/ + - /language/python/configure-ci-cd/ + - /guides/language/python/configure-ci-cd/ + - /guides/python/configure-ci-cd/ + - /guides/python/deploy/ + - /language/python/deploy/ + - /guides/language/python/deploy/ + - /guides/python/secure-supply-chain/ languages: [python] tags: [dhi] params: diff --git a/content/guides/r/_index.md b/content/guides/r/_index.md index 87c1a1795cd1..92ac34fa2a9d 100644 --- a/content/guides/r/_index.md +++ b/content/guides/r/_index.md @@ -10,6 +10,12 @@ toc_max: 2 aliases: - /languages/r/ - /guides/languages/r/ + - /guides/r/configure-ci-cd/ + - /language/r/configure-ci-cd/ + - /guides/language/r/configure-ci-cd/ + - /guides/r/deploy/ + - /language/r/deploy/ + - /guides/language/r/deploy/ languages: [r] params: time: 10 minutes diff --git a/content/guides/reactjs/_index.md b/content/guides/reactjs/_index.md index 7b8251ce3871..dd7ce4e66bd7 100644 --- a/content/guides/reactjs/_index.md +++ b/content/guides/reactjs/_index.md @@ -7,6 +7,9 @@ summary: | This guide explains how to containerize React.js applications using Docker. toc_min: 1 toc_max: 2 +aliases: + - /guides/reactjs/configure-github-actions/ + - /guides/reactjs/deploy/ languages: [js] params: time: 20 minutes diff --git a/content/guides/ruby/_index.md b/content/guides/ruby/_index.md index f241e8091fc7..999b6a6080ed 100644 --- a/content/guides/ruby/_index.md +++ b/content/guides/ruby/_index.md @@ -11,6 +11,13 @@ toc_max: 2 aliases: - /language/ruby/ - /guides/language/ruby/ + - /guides/ruby/configure-github-actions/ + - /language/ruby/configure-ci-cd/ + - /guides/language/ruby/configure-ci-cd/ + - /guides/ruby/configure-ci-cd/ + - /guides/ruby/deploy/ + - /language/ruby/deploy/ + - /guides/language/ruby/deploy/ languages: [ruby] tags: [frameworks] params: diff --git a/content/guides/rust/_index.md b/content/guides/rust/_index.md index ed3eee55af98..dfa62cd1f7aa 100644 --- a/content/guides/rust/_index.md +++ b/content/guides/rust/_index.md @@ -10,6 +10,12 @@ toc_max: 2 aliases: - /language/rust/ - /guides/language/rust/ + - /guides/rust/configure-ci-cd/ + - /language/rust/configure-ci-cd/ + - /guides/language/rust/configure-ci-cd/ + - /guides/rust/deploy/ + - /language/rust/deploy/ + - /guides/language/rust/deploy/ languages: [rust] tags: [dhi] params: diff --git a/content/guides/vuejs/_index.md b/content/guides/vuejs/_index.md index 645d57b66b11..371a92ad5fd8 100644 --- a/content/guides/vuejs/_index.md +++ b/content/guides/vuejs/_index.md @@ -11,6 +11,8 @@ languages: [js] tags: [frameworks, dhi] aliases: - /frameworks/vue/ + - /guides/vuejs/configure-github-actions/ + - /guides/vuejs/deploy/ params: time: 20 minutes