diff --git a/.github/CODEOWNERS b/.github/CODEOWNERS index c788520bb0..2b46baa5d8 100644 --- a/.github/CODEOWNERS +++ b/.github/CODEOWNERS @@ -255,7 +255,7 @@ /docs/deployments/databases/ @OctopusDeploy/team-modern-deployments -# updates to the deployments docker section are reviewed by team-modern-deployments +# updates to the deployments Docker section are reviewed by team-modern-deployments /docs/deployments/docker/ @OctopusDeploy/team-modern-deployments diff --git a/src/pages/docs/administration/upgrading/legacy/upgrading-from-octopus-3.x-to-modern.mdx b/src/pages/docs/administration/upgrading/legacy/upgrading-from-octopus-3.x-to-modern.mdx index d20f1c1570..82ef011ecd 100644 --- a/src/pages/docs/administration/upgrading/legacy/upgrading-from-octopus-3.x-to-modern.mdx +++ b/src/pages/docs/administration/upgrading/legacy/upgrading-from-octopus-3.x-to-modern.mdx @@ -36,7 +36,7 @@ You should be safe doing an in-place upgrade of 3.x to the latest version of Oct - Support for Kubernetes was introduced. - Terraform support was introduced. - Raised the [minimum requirements for hosting and using Octopus Server](https://octopus.com/blog/raising-minimum-requirements-for-octopus-server) (both Windows and SQL Server). -- Execution containers running on docker on workers were introduced. +- Execution containers running on Docker on workers were introduced. ## Prep work diff --git a/src/pages/docs/best-practices/octopus-administration/worker-configuration.md b/src/pages/docs/best-practices/octopus-administration/worker-configuration.md index c0f0855418..4a91791897 100644 --- a/src/pages/docs/best-practices/octopus-administration/worker-configuration.md +++ b/src/pages/docs/best-practices/octopus-administration/worker-configuration.md @@ -26,7 +26,7 @@ Some important items to note about workers: - Unlike deployment targets, workers are designed to run multiple tasks concurrently. - **Octopus Server 2020.1** added the [Worker Pool Variable Type](/docs/projects/variables/worker-pool-variables) making it possible to scope worker pools to environments. - **Octopus Server 2020.2** added the [execution container for workers](/docs/projects/steps/execution-containers-for-workers) feature, making it easier to manage software dependencies. -- We provide a [Tentacle docker image](https://hub.docker.com/repository/docker/octopusdeploy/tentacle) that can be configured to run as a worker. +- We provide a [Tentacle Docker image](https://hub.docker.com/repository/docker/octopusdeploy/tentacle) that can be configured to run as a worker. ## Provided Workers diff --git a/src/pages/docs/deployments/aws/ecs/index.md b/src/pages/docs/deployments/aws/ecs/index.md index d5d8200abb..acea539b73 100644 --- a/src/pages/docs/deployments/aws/ecs/index.md +++ b/src/pages/docs/deployments/aws/ecs/index.md @@ -18,7 +18,7 @@ At a high level, the `Deploy Amazon ECS Service` step will: * Select the Docker image tags for the task definition (version selection is performed when creating a release). * Build a CloudFormation template with: - * A task definition with the details specific to the deployment for the selected environment and docker image tags. + * A task definition with the details specific to the deployment for the selected environment and Docker image tags. * A service that references the task definition. * Perform variable substitution on the CloudFormation template. * Deploy a CloudFormation stack with the template. diff --git a/src/pages/docs/deployments/azure/running-azure-powershell/index.md b/src/pages/docs/deployments/azure/running-azure-powershell/index.md index f17666e9a6..54b1fdeae2 100644 --- a/src/pages/docs/deployments/azure/running-azure-powershell/index.md +++ b/src/pages/docs/deployments/azure/running-azure-powershell/index.md @@ -52,7 +52,7 @@ Octopus Cloud uses a special type of worker pool called a [Dynamic Worker Pool]( To use your own version of the Azure CLI or Azure PowerShell cmdlets when using Dynamic Worker Pools, please do the following: - Configure your step to use a Dynamic Worker pool that supports [execution containers](/docs/projects/steps/execution-containers-for-workers). -- Configure your step to run in an execution container with a [compatible docker image](/docs/projects/steps/execution-containers-for-workers/#which-image) that contains the versions of the Azure CLI or Azure PowerShell cmdlets that you would like to use. +- Configure your step to run in an execution container with a [compatible Docker image](/docs/projects/steps/execution-containers-for-workers/#which-image) that contains the versions of the Azure CLI or Azure PowerShell cmdlets that you would like to use. ## Run an Azure PowerShell script step diff --git a/src/pages/docs/deployments/custom-scripts/aws-cli-scripts.md b/src/pages/docs/deployments/custom-scripts/aws-cli-scripts.md index ebbd05fbae..12caacd83c 100644 --- a/src/pages/docs/deployments/custom-scripts/aws-cli-scripts.md +++ b/src/pages/docs/deployments/custom-scripts/aws-cli-scripts.md @@ -126,7 +126,7 @@ Octopus Cloud uses a special type of worker pool called a [Dynamic Worker Pool]( To use your own version of the AWS CLI or AWS PowerShell cmdlets when using Dynamic Worker Pools, please do the following: - Configure your step to use a Dynamic Worker pool that supports [execution containers](/docs/projects/steps/execution-containers-for-workers). -- Configure your step to run in an execution container with a [compatible docker image](/docs/projects/steps/execution-containers-for-workers/#which-image) that contains the versions of the AWS CLI or AWS PowerShell cmdlets that you would like to use. +- Configure your step to run in an execution container with a [compatible Docker image](/docs/projects/steps/execution-containers-for-workers/#which-image) that contains the versions of the AWS CLI or AWS PowerShell cmdlets that you would like to use. ## Older versions diff --git a/src/pages/docs/deployments/custom-scripts/azure-powershell-scripts.md b/src/pages/docs/deployments/custom-scripts/azure-powershell-scripts.md index 8409327179..2125bd00ee 100644 --- a/src/pages/docs/deployments/custom-scripts/azure-powershell-scripts.md +++ b/src/pages/docs/deployments/custom-scripts/azure-powershell-scripts.md @@ -48,7 +48,7 @@ Octopus Cloud uses a special type of worker pool called a [Dynamic Worker Pool]( To use your own version of the Azure CLI or Azure PowerShell cmdlets when using Dynamic Worker Pools, please do the following: - Configure your step to use a Dynamic Worker pool that supports [execution containers](/docs/projects/steps/execution-containers-for-workers). -- Configure your step to run in an execution container with a [compatible docker image](/docs/projects/steps/execution-containers-for-workers/#which-image) that contains the versions of the Azure CLI or Azure PowerShell cmdlets that you would like to use. +- Configure your step to run in an execution container with a [compatible Docker image](/docs/projects/steps/execution-containers-for-workers/#which-image) that contains the versions of the Azure CLI or Azure PowerShell cmdlets that you would like to use. These scripts are executed on the Octopus Server and will be pre-authenticated using the selected Azure Account. For information about adding a step to the deployment process, see the [add step](/docs/projects/steps) section. diff --git a/src/pages/docs/deployments/docker/docker-run-with-networking.md b/src/pages/docs/deployments/docker/docker-run-with-networking.md index cce22b3aa8..85145007aa 100644 --- a/src/pages/docs/deployments/docker/docker-run-with-networking.md +++ b/src/pages/docs/deployments/docker/docker-run-with-networking.md @@ -62,7 +62,7 @@ In a newly created project, click **Add Step ➜ Create a Docker network**. This ![](/docs/img/deployments/docker/images/add-docker-network-step.png) :::div{.hint} -**docker network support** +**Docker network support** Keep in mind that as the Docker Network Octopus step simply wraps the `docker network` command, you will need to ensure your installed version of docker-engine supports this command. This was provided as of the [1.9.0 Docker Engine release](https://github.com/docker/docker/blob/master/CHANGELOG/#networking-10). For detailed information about Docker networking and additional arguments you can provide, we suggest reading the [Understand Docker container networks](https://docs.docker.com/network/) and the [network create](https://docs.docker.com/engine/reference/commandline/network_create/) Docker documentation. @@ -98,7 +98,7 @@ The command itself is arbitrary. What is important is that we start a process th ### Step 3: Creating container 2 {#step3-create-container2} -Now we will create a second container, exactly the same as the first using busybox, but this container will connect to the first container to demonstrate how containers can communicate in a docker network. +Now we will create a second container, exactly the same as the first using busybox, but this container will connect to the first container to demonstrate how containers can communicate in a Docker network. 1. Create a new Run Docker Container step (very much like the first one, but notice some subtle differences): * Set the *Name* to **Second Server**. @@ -185,7 +185,7 @@ Looking at the results of a deployment you will see some logging indicating the **Having problems deploying to Docker?** Usually this will come down to problems with the Octopus Account you configured accessing the Docker daemon with messages like this: -`Cannot connect to the Docker daemon. Is the docker daemon running on this host?` +`Cannot connect to the Docker daemon. Is the Docker daemon running on this host?` For steps to grant the Octopus Account the ability to manage the Docker daemon, refer to the [Docker post-installation steps for Linux](https://docs.docker.com/engine/install/linux-postinstall/#manage-docker-as-a-non-root-user). ::: @@ -202,7 +202,7 @@ The Docker equivalent of the "Package Acquisition" phase involves retrieving the ![](/docs/img/deployments/docker/images/acquire-package-steps.png) ::: -When creating a network or container, the name and Id as simply echoed to the standard logs. The verbose logs will show the docker version on the target, the full docker command being called and if successful, the results of the inspect command that are passed to an output variable. +When creating a network or container, the name and Id as simply echoed to the standard logs. The verbose logs will show the Docker version on the target, the full Docker command being called and if successful, the results of the inspect command that are passed to an output variable. :::figure ![](/docs/img/deployments/docker/images/first-and-second-server-task-output.png) diff --git a/src/pages/docs/infrastructure/workers/dynamic-worker-pools.md b/src/pages/docs/infrastructure/workers/dynamic-worker-pools.md index 23152d0828..580ebd8699 100644 --- a/src/pages/docs/infrastructure/workers/dynamic-worker-pools.md +++ b/src/pages/docs/infrastructure/workers/dynamic-worker-pools.md @@ -154,7 +154,7 @@ Octopus does not recommend installing additional software on Dynamic Workers. By default, every dynamic worker is destroyed after it has been idle for 60 minutes or allocated for over 72 hours. Additionally, Octopus cannot guarantee that the dynamic worker leased to run one step will be the same worker leased to other executing steps in a deployment or runbook run. -For deployments and runbook runs that require additional software dependencies on a dynamic worker, our recommendation is to leverage [execution containers for workers](/docs/projects/steps/execution-containers-for-workers). Octopus provides execution containers with a baseline of tools (`octopusdeploy/worker-tools`) pre-installed. These tools won't include every possible software combination you might need. If you require a specific set of software and tooling we recommend [building your own custom docker images for use with execution containers](/docs/projects/steps/execution-containers-for-workers/#custom-docker-images). +For deployments and runbook runs that require additional software dependencies on a dynamic worker, our recommendation is to leverage [execution containers for workers](/docs/projects/steps/execution-containers-for-workers). Octopus provides execution containers with a baseline of tools (`octopusdeploy/worker-tools`) pre-installed. These tools won't include every possible software combination you might need. If you require a specific set of software and tooling we recommend [building your own custom Docker images for use with execution containers](/docs/projects/steps/execution-containers-for-workers/#custom-docker-images). :::div{.hint} **Octopus worker-tools are cached on Dynamic Workers** diff --git a/src/pages/docs/infrastructure/workers/dynamic-worker-pools/ubuntu-1804-end-of-life.md b/src/pages/docs/infrastructure/workers/dynamic-worker-pools/ubuntu-1804-end-of-life.md index 27f742aca6..3db0da46bd 100644 --- a/src/pages/docs/infrastructure/workers/dynamic-worker-pools/ubuntu-1804-end-of-life.md +++ b/src/pages/docs/infrastructure/workers/dynamic-worker-pools/ubuntu-1804-end-of-life.md @@ -92,5 +92,5 @@ Ubuntu 22.04 requires a later version of GCloud CLI. We have selected the earlie This change does not impact the Windows dynamic workers. ### How does this affect Execution Containers? -Although Ubuntu 18.04 docker images, along with [Worker Tools](/docs/infrastructure/workers/worker-tools-versioning-and-caching), can still operate on Ubuntu 22.04 dynamic workers, we will no longer provide support for the ubuntu.18.04 Worker Tools. Instead, we have introduced a new [ubuntu.22.04](https://hub.docker.com/r/octopusdeploy/worker-tools/tags?page=1&name=22.04) image, which is recommended moving forward. +Although Ubuntu 18.04 Docker images, along with [Worker Tools](/docs/infrastructure/workers/worker-tools-versioning-and-caching), can still operate on Ubuntu 22.04 dynamic workers, we will no longer provide support for the ubuntu.18.04 Worker Tools. Instead, we have introduced a new [ubuntu.22.04](https://hub.docker.com/r/octopusdeploy/worker-tools/tags?page=1&name=22.04) image, which is recommended moving forward. diff --git a/src/pages/docs/infrastructure/workers/kubernetes-worker/index.md b/src/pages/docs/infrastructure/workers/kubernetes-worker/index.md index cfa297626c..0bdf59c637 100644 --- a/src/pages/docs/infrastructure/workers/kubernetes-worker/index.md +++ b/src/pages/docs/infrastructure/workers/kubernetes-worker/index.md @@ -46,7 +46,7 @@ Of note: | Value | Purpose | | ----------------------------- | ------------------------------------------------------------------------- | -| scriptPods.worker.image | Specifies the docker container image to be used when running an operation | +| scriptPods.worker.image | Specifies the Docker container image to be used when running an operation | | scriptPods.resources.requests | Specifies the average cpu/memory usage required to execute an operation | If you are experiencing difficulties with your Kubernetes Cluster's autoscaling, modifying `scriptPods.resources.requests.*` @@ -72,5 +72,5 @@ Which means certain operations which are typically valid, may not be possible. Specifically: - Creating an [inline execution container](/docs/projects/steps/execution-containers-for-workers#inline-execution-containers) -- Fetching docker images (when used as secondary packages) +- Fetching Docker images (when used as secondary packages) - Arbitrary scripts which use docker diff --git a/src/pages/docs/infrastructure/workers/worker-tools-versioning-and-caching.md b/src/pages/docs/infrastructure/workers/worker-tools-versioning-and-caching.md index d00147a37a..6acbc3b406 100644 --- a/src/pages/docs/infrastructure/workers/worker-tools-versioning-and-caching.md +++ b/src/pages/docs/infrastructure/workers/worker-tools-versioning-and-caching.md @@ -3,16 +3,16 @@ layout: src/layouts/Default.astro pubDate: 2023-01-01 modDate: 2023-01-01 title: Worker Tools, Versioning and Caching -description: How Octopus creates, versions, caches, and releases the worker-tools docker images for use with the execution containers for workers feature. +description: How Octopus creates, versions, caches, and releases the worker-tools Docker images for use with the execution containers for workers feature. navOrder: 50 --- -Worker Tools are a set of docker images used as [execution containers for workers](https://octopus.com/docs/projects/steps/execution-containers-for-workers) to run deployment processes. Worker Tools include a wide range of software tools to support most deployment scenarios out of the box. This page focuses on how we create these Worker Tool images, version, cache on workers, and release them. +Worker Tools are a set of Docker images used as [execution containers for workers](https://octopus.com/docs/projects/steps/execution-containers-for-workers) to run deployment processes. Worker Tools include a wide range of software tools to support most deployment scenarios out of the box. This page focuses on how we create these Worker Tool images, version, cache on workers, and release them. ## Versioning Worker Tools Worker Tool images follow a semantic versioning (SemVer) approach of `Major.Minor.Patch-Distro` for their tag format. When we release a new version of Worker Tools to the [Worker Tools Docker Hub repository](https://hub.docker.com/r/octopusdeploy/worker-tools/tags), we also add the following image tags, distribution (`ubuntu.22.04` or `windows.ltsc2022`), `Major-Distro` (e.g. `3-Distro`) and `Major.Minor-Distro` (`3.3-Distro`). We recommend using the fully qualified SemVer as patch updates of Worker Tools could result in an updated tool dependency introducing a breaking change. -The Worker Tools Dockerfiles use a combination of tools pinned to specific versions, such as CLI tools and Frameworks, while other tools pull their latest available release. For Ubuntu, these are pulled with apt-get, and for Windows, chocolatey. You can find the full details of these tools in the docker files for [Windows](https://github.com/OctopusDeploy/WorkerTools/blob/master/windows.ltsc2022/Dockerfile) and [Ubuntu](https://github.com/OctopusDeploy/WorkerTools/blob/master/ubuntu.22.04/Dockerfile) Worker Tools. +The Worker Tools Dockerfiles use a combination of tools pinned to specific versions, such as CLI tools and Frameworks, while other tools pull their latest available release. For Ubuntu, these are pulled with apt-get, and for Windows, chocolatey. You can find the full details of these tools in the Docker files for [Windows](https://github.com/OctopusDeploy/WorkerTools/blob/master/windows.ltsc2022/Dockerfile) and [Ubuntu](https://github.com/OctopusDeploy/WorkerTools/blob/master/ubuntu.22.04/Dockerfile) Worker Tools. The tools pulling their latest releases for Ubuntu include `wget`, `python3-pip`, `groff`, `unzip`, `apt-utils`, `curl`, `software-properties-common`, `jq`, `yq`, `openssh-client`, `rsync`, `git`, `augeas-tools`, `maven`, `gradle`, `Node 14`, `istioctl`, `linkerd `, `umoci`. @@ -39,7 +39,7 @@ In short, we recommend using the full `octopusdeploy/worker-tools:Major.Minor.Pa Worker Tools are cached on dynamic workers to help improve the performance of deployments. Windows workers cache the latest two sets of Worker Tools while Ubuntu workers cache the latest five. -To understand this cache, it's important to understand a worker's life cycle. Workers are acquired from a dynamic worker pool and leased to a single cloud instance. They are allocated in a round robin fashion to individual deployment steps, storing packages, docker images, and other data on disk. Workers are destroyed after either the worker has been idle for 60 minutes or has existed for 72 hours (3 days). +To understand this cache, it's important to understand a worker's life cycle. Workers are acquired from a dynamic worker pool and leased to a single cloud instance. They are allocated in a round robin fashion to individual deployment steps, storing packages, Docker images, and other data on disk. Workers are destroyed after either the worker has been idle for 60 minutes or has existed for 72 hours (3 days). When a new worker is acquired, if a new set of Worker Tools has been released, the worker will no longer have the oldest version of Worker Tools, and any other images pulled on the old worker. This is important for the performance of deployments as pull times for uncached Worker Tools are ~1.5 minutes for Ubuntu and ~20 minutes for Windows. We recommend updating to the latest set of Worker Tools available to avoid these pull times. By Caching multiple versions of Worker Tools when using the latest version, any new release of Worker Tools will not result in degraded deployment performance. @@ -61,4 +61,4 @@ Using non-cached versions of these worker-tools can result in long downloads. ## Learn more - [Worker blog posts](https://octopus.com/blog/tag/workers/1) -- [Custom docker images](/docs/projects/steps/execution-containers-for-workers/#custom-docker-images) +- [Custom Docker images](/docs/projects/steps/execution-containers-for-workers/#custom-docker-images) diff --git a/src/pages/docs/installation/load-balancers/use-nginx-as-reverse-proxy.md b/src/pages/docs/installation/load-balancers/use-nginx-as-reverse-proxy.md index cf589978a3..e39ce705ed 100644 --- a/src/pages/docs/installation/load-balancers/use-nginx-as-reverse-proxy.md +++ b/src/pages/docs/installation/load-balancers/use-nginx-as-reverse-proxy.md @@ -103,7 +103,7 @@ docker build -t octopusbob/nginx:1.0.0 -t octopusbob/nginx:latest . ``` ### Running the NGINX Container -Then you can run the docker image in a container by running the command. +Then you can run the Docker image in a container by running the command. ``` docker run --name octopus-reverse-proxy -p 443:443 -e OCTOPUS_SERVER=servername:8080 octopusbob/nginx:latest diff --git a/src/pages/docs/kubernetes/resources/kubectl.md b/src/pages/docs/kubernetes/resources/kubectl.md index bec5a9d236..fdfe38333f 100644 --- a/src/pages/docs/kubernetes/resources/kubectl.md +++ b/src/pages/docs/kubernetes/resources/kubectl.md @@ -9,6 +9,6 @@ navOrder: 100 The [kubectl command-line tool](https://kubernetes.io/docs/reference/kubectl/overview/) is required by Octopus Deploy's Kubernetes features. -`kubectl` is not bundled with Octopus, and must be pre-installed on the [worker](/docs/infrastructure/workers/) or Octopus Server which will execute steps and health checks against a [Kubernetes target](/docs/kubernetes/targets/kubernetes-api). Alternatively, [execution containers](/docs/projects/steps/execution-containers-for-workers) may be used and we recommend using [`octopuslabs/k8s-workertools`](https://hub.docker.com/r/octopuslabs/k8s-workertools) docker image, we also recommend setting the tag to a version that is compatible with the version of your cluster, [read the official version skew policy](https://kubernetes.io/releases/version-skew-policy/#kubectl) for more information. +`kubectl` is not bundled with Octopus, and must be pre-installed on the [worker](/docs/infrastructure/workers/) or Octopus Server which will execute steps and health checks against a [Kubernetes target](/docs/kubernetes/targets/kubernetes-api). Alternatively, [execution containers](/docs/projects/steps/execution-containers-for-workers) may be used and we recommend using [`octopuslabs/k8s-workertools`](https://hub.docker.com/r/octopuslabs/k8s-workertools) Docker image, we also recommend setting the tag to a version that is compatible with the version of your cluster, [read the official version skew policy](https://kubernetes.io/releases/version-skew-policy/#kubectl) for more information. By default, Octopus assumes `kubectl` is available in the PATH environment variable. A specific location for `kubectl` can be supplied by setting a `Octopus.Action.Kubernetes.CustomKubectlExecutable` variable in the Octopus project (an example value is `c:\tools\kubectl\version\kubectl.exe`). diff --git a/src/pages/docs/kubernetes/targets/kubernetes-agent/images.md b/src/pages/docs/kubernetes/targets/kubernetes-agent/images.md index ece2ad889b..f29855d0d3 100644 --- a/src/pages/docs/kubernetes/targets/kubernetes-agent/images.md +++ b/src/pages/docs/kubernetes/targets/kubernetes-agent/images.md @@ -106,7 +106,7 @@ The default image used for workloads when running as a worker. :::div{.hint} -For ARM workloads use **octopuslabs/k8s-workertools** or your own [custom docker image](/docs/projects/steps/execution-containers-for-workers#custom-docker-images). +For ARM workloads use **octopuslabs/k8s-workertools** or your own [custom Docker image](/docs/projects/steps/execution-containers-for-workers#custom-docker-images). ### octopuslabs/k8s-workertools diff --git a/src/pages/docs/octopus-ai/assistant/custom-prompts.md b/src/pages/docs/octopus-ai/assistant/custom-prompts.md index a8faa1b0f6..58ed0527d6 100644 --- a/src/pages/docs/octopus-ai/assistant/custom-prompts.md +++ b/src/pages/docs/octopus-ai/assistant/custom-prompts.md @@ -76,7 +76,7 @@ For example: | Variable name | Variable value | |----------|-------| -| `Project.Deployment[0].SystemPrompt` | If the logs indicate that a Docker image is missing, You must only provide the suggestion that the user must visit to get additional instructions to resolve missing docker containers. You will be penalized for offering generic suggestions to resolve a missing docker image. You will be penalized for offering script suggestions to resolve a missing docker image. You will be penalized for suggesting step retries to resolve a missing docker image. | +| `Project.Deployment[0].SystemPrompt` | If the logs indicate that a Docker image is missing, You must only provide the suggestion that the user must visit to get additional instructions to resolve missing Docker containers. You will be penalized for offering generic suggestions to resolve a missing Docker image. You will be penalized for offering script suggestions to resolve a missing Docker image. You will be penalized for suggesting step retries to resolve a missing Docker image. | This system prompt is sent to the LLM to provide specific instructions on how to respond to the request, and: diff --git a/src/pages/docs/octopus-rest-api/cli/octopus-deployment-target-kubernetes-create.mdx b/src/pages/docs/octopus-rest-api/cli/octopus-deployment-target-kubernetes-create.mdx index d0749f9d87..fc424ab069 100644 --- a/src/pages/docs/octopus-rest-api/cli/octopus-deployment-target-kubernetes-create.mdx +++ b/src/pages/docs/octopus-rest-api/cli/octopus-deployment-target-kubernetes-create.mdx @@ -27,7 +27,7 @@ Flags: --certificate-path string The path to the CA certificate of the cluster. The default value usually is: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt --client-certificate string Name of client certificate in Octopus Deploy --cluster-url string Kubernetes cluster URL. Must be an absolute URL. e.g. https://kubernetes.example.com - --docker-container-registry string The feed of the docker container registry to use if running health check in a container on the worker + --docker-container-registry string The feed of the Docker container registry to use if running health check in a container on the worker --docker-image-flags string The image (including the tag) to use from the container registry --eks-assume-service-role Assume a different AWS service role. --eks-assumed-role-arn string ARN of assumed AWS service role. diff --git a/src/pages/docs/packaging-applications/build-servers/bitbucket-pipelines/index.mdx b/src/pages/docs/packaging-applications/build-servers/bitbucket-pipelines/index.mdx index 7dcfef7cfe..7bf96c94c2 100644 --- a/src/pages/docs/packaging-applications/build-servers/bitbucket-pipelines/index.mdx +++ b/src/pages/docs/packaging-applications/build-servers/bitbucket-pipelines/index.mdx @@ -9,7 +9,7 @@ navOrder: 40 [Bitbucket](https://bitbucket.org/) is a git-based source-control platform made by Atlassian that serves as an alternative to GitHub with free unlimited private repos. -[Bitbucket Pipelines](https://bitbucket.org/product/features/pipelines) is Atlassian's cloud-based continuous integration server, built using pre-configured docker containers. +[Bitbucket Pipelines](https://bitbucket.org/product/features/pipelines) is Atlassian's cloud-based continuous integration server, built using pre-configured Docker containers. :::div{.warning} As Bitbucket Pipelines is only available as a cloud offering, your Octopus Server must be accessible over the Internet. diff --git a/src/pages/docs/packaging-applications/build-servers/codefresh-pipelines.md b/src/pages/docs/packaging-applications/build-servers/codefresh-pipelines.md index 4ed4c36ad8..1829ee8944 100644 --- a/src/pages/docs/packaging-applications/build-servers/codefresh-pipelines.md +++ b/src/pages/docs/packaging-applications/build-servers/codefresh-pipelines.md @@ -12,7 +12,7 @@ Codefresh is a docker-native CI/CD platform [Codefresh Pipelines](https://codefresh.io/docs/docs/pipelines/introduction-to-codefresh-pipelines/) are workflows that form Codefresh's continuous integration (CI) platform. # Integrating with Codefresh Pipelines -Codefresh pipelines allow you to customize steps to create, deploy and promote releases to your Octopus Deploy [environments](/docs/infrastructure/environments/). The steps do this by running the [Octopus CLI](/docs/octopus-rest-api/octopus-cli) inside a docker container. +Codefresh pipelines allow you to customize steps to create, deploy and promote releases to your Octopus Deploy [environments](/docs/infrastructure/environments/). The steps do this by running the [Octopus CLI](/docs/octopus-rest-api/octopus-cli) inside a Docker container. Octopus Deploy has several custom pipeline steps available: diff --git a/src/pages/docs/packaging-applications/package-repositories/docker-registries/octopus-version.md b/src/pages/docs/packaging-applications/package-repositories/docker-registries/octopus-version.md index 35edd3469a..9c4f1ad105 100644 --- a/src/pages/docs/packaging-applications/package-repositories/docker-registries/octopus-version.md +++ b/src/pages/docs/packaging-applications/package-repositories/docker-registries/octopus-version.md @@ -17,7 +17,7 @@ Starting with 2020.6, Octopus introduced a new, permissive versioning scheme for Prior to 2020.6, Octopus only recognized Docker image tags that complied with the Semantic Versioning standard. ::: -The following [regular expression](https://oc.to/OctopusVersionRegex/) defines how docker tags are parsed into version components: +The following [regular expression](https://oc.to/OctopusVersionRegex/) defines how Docker tags are parsed into version components: ``` ^(?:(?v|V)?(?\d+)(?:\.(?\d+))?(?:\.(?\d+))?(?:\.(?\d+))?)?(?:[.\-_])?(?(?[^+.\-_\s]*?)([.\-_](?[^+\s]*?)?)?)?(?:\+(?[^\s]*?))?$ diff --git a/src/pages/docs/packaging-applications/package-repositories/guides/container-registries/amazon-ec2-container-services.md b/src/pages/docs/packaging-applications/package-repositories/guides/container-registries/amazon-ec2-container-services.md index 92f54e21a7..2b55adf12f 100644 --- a/src/pages/docs/packaging-applications/package-repositories/guides/container-registries/amazon-ec2-container-services.md +++ b/src/pages/docs/packaging-applications/package-repositories/guides/container-registries/amazon-ec2-container-services.md @@ -24,7 +24,7 @@ Under the `Repositories` area you need to create a repository to match the what ![AWS Registries](/docs/img/packaging-applications/package-repositories/guides/container-registries/images/aws-registries.png) ::: -With the repository configured, ensure that you also have an [AWS IAM](https://aws.amazon.com/iam/) user available that has at a minimum the permissions `ecr:GetAuthorizationToken`, `ecr:DescribeRepositories`, `ecr:DescribeImages` and `ecr:ListImages`. This user is the account which Octopus will use to retrieve the docker login token which is then used to perform the appropriate docker commands. +With the repository configured, ensure that you also have an [AWS IAM](https://aws.amazon.com/iam/) user available that has at a minimum the permissions `ecr:GetAuthorizationToken`, `ecr:DescribeRepositories`, `ecr:DescribeImages` and `ecr:ListImages`. This user is the account which Octopus will use to retrieve the Docker login token which is then used to perform the appropriate Docker commands. Further links for getting your AWS registry set up are available in their [online docs](http://docs.aws.amazon.com/AmazonECR/latest/userguide/what-is-ecr.html) diff --git a/src/pages/docs/packaging-applications/package-repositories/guides/container-registries/azure-container-services.md b/src/pages/docs/packaging-applications/package-repositories/guides/container-registries/azure-container-services.md index 0068539e19..551e96621c 100644 --- a/src/pages/docs/packaging-applications/package-repositories/guides/container-registries/azure-container-services.md +++ b/src/pages/docs/packaging-applications/package-repositories/guides/container-registries/azure-container-services.md @@ -7,7 +7,7 @@ description: How to add an Azure Container Registry as an Octopus Deploy feed navOrder: 40 --- -Microsoft Azure provides a docker image registry known as [Azure Container Registry](https://azure.microsoft.com/en-au/services/container-registry/). +Microsoft Azure provides a Docker image registry known as [Azure Container Registry](https://azure.microsoft.com/en-au/services/container-registry/). ## Configuring an Azure Container Registry diff --git a/src/pages/docs/packaging-applications/package-repositories/guides/container-registries/docker-hub.md b/src/pages/docs/packaging-applications/package-repositories/guides/container-registries/docker-hub.md index 8183906913..6013e4e8b2 100644 --- a/src/pages/docs/packaging-applications/package-repositories/guides/container-registries/docker-hub.md +++ b/src/pages/docs/packaging-applications/package-repositories/guides/container-registries/docker-hub.md @@ -7,7 +7,7 @@ description: How to add Docker Hub as an Octopus Deploy feed for use in Docker s navOrder: 50 --- -The default Docker Registry, which is maintained by the Docker organization, is the cloud-hosted [Docker Hub Registry](https://hub.docker.com/). This is the Registry which is used by docker engine when it is first installed and you call `docker search`. +The default Docker Registry, which is maintained by the Docker organization, is the cloud-hosted [Docker Hub Registry](https://hub.docker.com/). This is the Registry which is used by Docker engine when it is first installed and you call `docker search`. From September 5th 2022, the Docker Hub Registry is [deprecating v1 endpoints](https://www.docker.com/blog/docker-hub-v1-api-deprecation) to retrieve tags and images. The equivalent v2 endpoints require authentication. Therefore, external feeds will require a username and password to access the Docker Hub API. Searching for repositories of a non-official repository will also require you to provide your Docker Hub username and password. Searching for official public repositories does not require credentials. diff --git a/src/pages/docs/packaging-applications/package-repositories/guides/container-registries/nexus-container-registry.md b/src/pages/docs/packaging-applications/package-repositories/guides/container-registries/nexus-container-registry.md index 8f6d7bff9e..ab49b67a35 100644 --- a/src/pages/docs/packaging-applications/package-repositories/guides/container-registries/nexus-container-registry.md +++ b/src/pages/docs/packaging-applications/package-repositories/guides/container-registries/nexus-container-registry.md @@ -6,12 +6,12 @@ title: Nexus Container Registry description: How to add a Nexus Docker Registry as an Octopus feed navOrder: 80 --- -Sonatype Nexus Repository Manager offers three types of docker registry; +Sonatype Nexus Repository Manager offers three types of Docker registry; - Group - Hosted - Proxy -This guide will focus on adding a `Hosted` docker registry as an External Octopus Feed. +This guide will focus on adding a `Hosted` Docker registry as an External Octopus Feed. :::div{.info} @@ -38,18 +38,18 @@ Click **Create repository** ![Create repository](/docs/img/packaging-applications/package-repositories/guides/images/nexus-create-repository.png) ::: -Choose **docker (hosted)** from the list of repositories to create +Choose **Docker (hosted)** from the list of repositories to create :::figure ![Docker hosted](/docs/img/packaging-applications/package-repositories/guides/container-registries/images/nexus-create-docker-repository.png) ::: -Give the repository a name and change any applicable configuration options. When using HTTPS, a Nexus docker repository will listen on the specified port. +Give the repository a name and change any applicable configuration options. When using HTTPS, a Nexus Docker repository will listen on the specified port. Click **Create repository** when you are done. :::figure -![Create Nexus docker repository](/docs/img/packaging-applications/package-repositories/guides/container-registries/images/nexus-docker-repository.png) +![Create Nexus Docker repository](/docs/img/packaging-applications/package-repositories/guides/container-registries/images/nexus-docker-repository.png) ::: When the repository has been created, click on the entry in the list to bring up the repository properties. diff --git a/src/pages/docs/projects/project-triggers/external-feed-triggers.md b/src/pages/docs/projects/project-triggers/external-feed-triggers.md index 34358f6fe2..a9c64bed51 100644 --- a/src/pages/docs/projects/project-triggers/external-feed-triggers.md +++ b/src/pages/docs/projects/project-triggers/external-feed-triggers.md @@ -88,7 +88,7 @@ When you are using external feed triggers there are a few reasons why a release 1. **Inspect the task list** for errors in the **Task** menu - Octopus will log the reason why external feed triggers failed as errors or warnings. Note that external feed triggers are system tasks, and do not display in the list by default. Use the **Show advanced filters** option and select **Include system tasks** to show them. -2. Ensure you are pushing the package to a **supported external feed type**. While capability has been verified against most major docker providers, compatibility is not guaranteed - please contact Octopus Deploy support if you encounter any problems. +2. Ensure you are pushing the package to a **supported external feed type**. While capability has been verified against most major Docker providers, compatibility is not guaranteed - please contact Octopus Deploy support if you encounter any problems. 3. Ensure that packages in the external feed match the [channel rules](/docs/releases/channels#version-rules) if defined for the trigger's channel (or the default channel if your project doesn't have multiple channels). **Triggers will only create a new release if the packages match channel rules.** diff --git a/src/pages/docs/projects/steps/execution-containers-for-workers/index.mdx b/src/pages/docs/projects/steps/execution-containers-for-workers/index.mdx index 111ef4b5fa..21f34b1485 100644 --- a/src/pages/docs/projects/steps/execution-containers-for-workers/index.mdx +++ b/src/pages/docs/projects/steps/execution-containers-for-workers/index.mdx @@ -42,7 +42,7 @@ You need Docker installed and running on the [worker](/docs/infrastructure/worke ![](/docs/img/projects/steps/execution-containers-for-workers/images/container-selector-image.png) ::: -## First deployment on a docker container +## First deployment on a Docker container :::div{.hint} Pre-pulling your chosen image will save you time during deployments. @@ -50,7 +50,7 @@ Pre-pulling your chosen image will save you time during deployments. When you choose to run one or more of your deployment steps in a container, your deployment process will `docker pull` the image you provide at the start of each deployment during package acquisition. -For your first deployment this may take a while since your docker image won't be cached. You can pre-pull the desired docker image on your worker before your first deployment to avoid any delays. +For your first deployment this may take a while since your Docker image won't be cached. You can pre-pull the desired Docker image on your worker before your first deployment to avoid any delays. ## Which Docker images can I use? \{#which-image} @@ -60,9 +60,9 @@ The easiest way to get started is to use the [worker-tools](#worker-tools-images When a step is configured to use an execution container, you can choose from: - One of the [worker-tools](#worker-tools-images) images built by Octopus Deploy. -- A [custom docker image](#custom-docker-images) you build. +- A [custom Docker image](#custom-docker-images) you build. -If you run into issues with the provided [worker-tools](#worker-tools-images) images or they don't meet your needs, you will have to create a custom image. Take a look at the [custom docker image](#custom-docker-images) section or the [blog post on extending execution containers](https://octopus.com/blog/extending-octopus-execution-container) to learn how to create a custom image. +If you run into issues with the provided [worker-tools](#worker-tools-images) images or they don't meet your needs, you will have to create a custom image. Take a look at the [custom Docker image](#custom-docker-images) section or the [blog post on extending execution containers](https://octopus.com/blog/extending-octopus-execution-container) to learn how to create a custom image. ### The octopusdeploy/worker-tools Docker images \{#worker-tools-images} @@ -90,7 +90,7 @@ Some of the tools included are: - Terraform - Python -### Custom docker images \{#custom-docker-images} +### Custom Docker images \{#custom-docker-images} It can be beneficial to build your own custom Docker image when using execution containers, particularly when you wish the image size to be as small as possible. @@ -136,7 +136,7 @@ If your chosen Docker image does not have these prerequisites, the easiest solut Microsoft also provides [base images that include these dependencies](https://hub.docker.com/r/microsoft/dotnet-runtime-deps). -#### Custom docker image example +#### Custom Docker image example The following example is a basic Docker file that (when built) can run Calamari and PowerShell scripts: @@ -167,7 +167,7 @@ RUN curl -LO -k "https://packages.microsoft.com/config/ubuntu/20.04/packages-mic rm -f packages-microsoft-prod.deb ``` -To learn more about creating a custom docker image, we have a [detailed blog post](https://octopus.com/blog/extending-octopus-execution-container) that describes how to get started and the minimum set of dependencies you would need. +To learn more about creating a custom Docker image, we have a [detailed blog post](https://octopus.com/blog/extending-octopus-execution-container) that describes how to get started and the minimum set of dependencies you would need. #### Inline execution containers @@ -175,7 +175,7 @@ To learn more about creating a custom docker image, we have a [detailed blog pos Support for inline execution containers requires Octopus version 2024.1 ::: -To improve the experience of using custom docker images on steps in Octopus we're expanding our execution containers feature to include options to provide the Dockerfile from a [Git URL](#docker-image-from-git-url) or an [Inline Dockerfile](#docker-image-from-inline-dockerfile) that will be built and used as the container that the step is executed on. +To improve the experience of using custom Docker images on steps in Octopus we're expanding our execution containers feature to include options to provide the Dockerfile from a [Git URL](#docker-image-from-git-url) or an [Inline Dockerfile](#docker-image-from-inline-dockerfile) that will be built and used as the container that the step is executed on. This will make it easier and quicker to iterate on building a Docker image best suited to different scenarios. diff --git a/src/pages/docs/releases/issue-tracking/jira.md b/src/pages/docs/releases/issue-tracking/jira.md index 236bc903f8..49860889d6 100644 --- a/src/pages/docs/releases/issue-tracking/jira.md +++ b/src/pages/docs/releases/issue-tracking/jira.md @@ -232,7 +232,7 @@ If you have a [built-in package repository trigger](/docs/projects/project-trigg ### Check the entire package ID {#troubleshooting-check-the-entire-package-id} -If you find your work items or other build information aren't showing up in your releases, make sure your package ID as shown in the release is the exact same as it is found in the **Library ➜ Build Information** section. Some package ID values, particularly those found in external feeds must include the repository. For example, if you were pushing build information for the docker image `octopusdeploy/worker-tools`, the value for the package ID needs to include the repository name of `octopusdeploy/` as well as the name of the docker image, not just `worker-tools`. +If you find your work items or other build information aren't showing up in your releases, make sure your package ID as shown in the release is the exact same as it is found in the **Library ➜ Build Information** section. Some package ID values, particularly those found in external feeds must include the repository. For example, if you were pushing build information for the Docker image `octopusdeploy/worker-tools`, the value for the package ID needs to include the repository name of `octopusdeploy/` as well as the name of the Docker image, not just `worker-tools`. ### Check the package ID is not dynamically generated {#troubleshooting-check-dynamic-package-id} diff --git a/src/pages/docs/security/hardening-octopus.mdx b/src/pages/docs/security/hardening-octopus.mdx index c079b9605a..2f2d62f55c 100644 --- a/src/pages/docs/security/hardening-octopus.mdx +++ b/src/pages/docs/security/hardening-octopus.mdx @@ -342,7 +342,7 @@ The TCP ports listed below are defaults, and can be changed if required - refer If you run an [Octopus Deploy container](/docs/installation/octopus-server-linux-container), in addition to your usual security measure for running apps out of containers, take the following steps to secure it: -- Move your docker data directory (the default location is `/var/lib/docker`) so that your containers are stored on a separate partition. +- Move your Docker data directory (the default location is `/var/lib/docker`) so that your containers are stored on a separate partition. - Assign resources carefully: - Consider pinning CPUs to namespaces in order to give them a boundary. - Consider the amount of memory required, if you assign too much the container is susceptible to denial of service attacks, but if you assign too little or make use of memory ballooning performance will be impacted. diff --git a/src/shared-content/concepts/octopus-deploy-setup-options.include.md b/src/shared-content/concepts/octopus-deploy-setup-options.include.md index 2e6d293e17..bd96d849de 100644 --- a/src/shared-content/concepts/octopus-deploy-setup-options.include.md +++ b/src/shared-content/concepts/octopus-deploy-setup-options.include.md @@ -1,3 +1,3 @@ - [Octopus Cloud](https://octopus.com/free-signup) -> we host the Octopus Deploy instance for you, it connects to your servers. - [Self-hosted on a Windows Server](https://octopus.com/free-signup) -> you host it on your infrastructure by [downloading our MSI](https://octopus.com/download) and installing it onto a Windows Server with a SQL Server backend. Learn more about [our installation requirements](/docs/installation/requirements). -- [Self-hosted as a Docker container](https://octopus.com/blog/introducing-linux-docker-image) -> you run Octopus Deploy in a docker container. You will still need a [free license](https://octopus.com/free-signup). \ No newline at end of file +- [Self-hosted as a Docker container](https://octopus.com/blog/introducing-linux-docker-image) -> you run Octopus Deploy in a Docker container. You will still need a [free license](https://octopus.com/free-signup). \ No newline at end of file diff --git a/src/shared-content/octopus-recommendations/project-recommendations.include.md b/src/shared-content/octopus-recommendations/project-recommendations.include.md index a705e2364c..fd86c4760e 100644 --- a/src/shared-content/octopus-recommendations/project-recommendations.include.md +++ b/src/shared-content/octopus-recommendations/project-recommendations.include.md @@ -65,13 +65,13 @@ The workflow would be as follows: 9. Automated tests are run in Staging. 10. Assuming tests pass, promote to Production. If tests don't pass, then a new branch is created, and this process starts all over. -Octopus Deploy provides the capability for dynamic package / docker image selection. This allows you to have a different package per environment. The intended use case is when using a third-party external feed and the feed changes between environments. The external feed provides the capabilities to "promote" packages ready for deployment. +Octopus Deploy provides the capability for dynamic package / Docker image selection. This allows you to have a different package per environment. The intended use case is when using a third-party external feed and the feed changes between environments. The external feed provides the capabilities to "promote" packages ready for deployment. We don't recommend having a single lifecycle with all environments. When that happens, we have seen customers create a single release and change the package or package version from QA to Staging. Such an approach is challenging to audit and track. Changes made on feature or short-lived branches are not ready for Production. They should be deployed to testing environments for verification and testing, but they should never have the chance to make it to Production. Merging into main should trigger a fresh build because you could be merging multiple changes from different branches for the first time. The underlying code has changed, and a new build is needed to test and verify. -For the packages / docker containers built from branches, append a pre-release tag to the release version. Leverage channel version rules to only allow packages / docker containers with a pre-release tag for the Development lifecycle. At the same time, only allow packages / docker containers **without** a pre-release tag for the release lifecycle. +For the packages / Docker containers built from branches, append a pre-release tag to the release version. Leverage channel version rules to only allow packages / Docker containers with a pre-release tag for the Development lifecycle. At the same time, only allow packages / Docker containers **without** a pre-release tag for the release lifecycle. :::div{.hint} This section is another reason we recommend deploying all tightly coupled components stored in the same source control repository within the same project. Attempting to coordinate different lifecycles and releases across multiple projects can add additional overhead, which runs the risk of something needing to be fixed.