[ { "path": ".atlassian/OWNER", "content": "abrokes" }, { "path": ".github/CODEOWNERS", "content": "* @nanux @yzha645 @bianchi2 @kush982 @amierzwicki @pbhardwaj6 @jainanshul43 @jwitowski-atl\n" }, { "path": ".github/ISSUE_TEMPLATE/FEATURE.yml", "content": "name: Feature request\ndescription: Do you have an idea or suggestion for a Helm charts improvement?\ntitle: \"[Suggestion] - \"\nlabels: [suggestion, triage]\nbody:\n - type: markdown\n attributes:\n value: |\n ## 💡 Feature requests only 💡\n \n Thanks for taking the time to suggest a new feature! If you are experiencing issues in Helm chart installation, please read [Supported Boundaries document](https://atlassian.github.io/data-center-helm-charts/troubleshooting/SUPPORT_BOUNDARIES/) and contact [Atlassian Support directly](https://support.atlassian.com/contact/).\n - type: textarea\n id: suggestion-description\n attributes:\n label: Suggestion\n description: Describe your idea in detail, including the use case when it will be useful\n validations:\n required: true\n - type: dropdown\n id: version\n attributes:\n label: Product\n description: You can select multiple products\n options:\n - Jira\n - Confluence\n - Bitbucket\n - Other\n multiple: true\n validations:\n required: false\n - type: checkboxes\n id: terms\n attributes:\n label: Code of Conduct\n description: By submitting this issue, you agree to follow our [Code of Conduct](https://github.com/atlassian/data-center-helm-charts/blob/main/CODE_OF_CONDUCT.md)\n options:\n - label: I agree to follow this project's Code of Conduct\n required: true\n" }, { "path": ".github/ISSUE_TEMPLATE/config.yml", "content": "blank_issues_enabled: false\ncontact_links:\n - name: ⚠️ Support boundaries ⚠️\n url: https://atlassian.github.io/data-center-helm-charts/troubleshooting/SUPPORT_BOUNDARIES/\n about: Please read the scope of support before raising an issue\n - name: Helm installation issues\n url: https://support.atlassian.com/contact/\n about: Contact Atlassian Support with issues relating to Helm installation\n - name: Q & A Community forum\n url: https://community.atlassian.com/t5/Atlassian-Data-Center-on/gh-p/DC_Kubernetes\n about: For anyone who’s interested in learning more about K8s, and how they can deploy their Data Center products using the Helm Charts\n" }, { "path": ".github/pull_request_template.md", "content": "## Pull request description\n\n_Provide description for the PR_\n\n## Checklist\n- [ ] I have added unit tests\n- [ ] I have applied the change to all applicable products\n- [ ] The E2E test has passed (use `e2e` label)\n" }, { "path": ".github/workflows/crc.yaml", "content": "# This workflow is for testing Helm charts in MicroShift\n\nname: DC Tests in MicroShift\n\non:\n schedule:\n - cron: '0 3 */2 * *' # schedule the test to run every second day at 3:00am\n workflow_dispatch:\n push:\n branches:\n - main\n paths:\n - 'src/main/charts/bamboo/**'\n - 'src/main/charts/bamboo-agent/**'\n - 'src/main/charts/bitbucket/**'\n - 'src/main/charts/confluence/**'\n - 'src/main/charts/jira/**'\n - 'src/main/charts/crowd/**'\n pull_request_target:\n types: [ labeled ]\n\njobs:\n jira:\n uses: ./.github/workflows/openshift.yaml\n with:\n dc_app: jira\n secrets:\n JIRA_LICENSE: \"${{ secrets.JIRA_LICENSE }}\"\n OPENSHIFT_PULL_SECRET: \"${{ secrets.OPENSHIFT_PULL_SECRET }}\"\n\n confluence:\n uses: ./.github/workflows/openshift.yaml\n with:\n dc_app: confluence\n secrets:\n CONFLUENCE_LICENSE: \"${{ secrets.TF_VAR_CONFLUENCE_LICENSE }}\"\n OPENSHIFT_PULL_SECRET: \"${{ secrets.OPENSHIFT_PULL_SECRET }}\"\n\n bitbucket:\n uses: ./.github/workflows/openshift.yaml\n with:\n dc_app: bitbucket\n secrets:\n BITBUCKET_LICENSE: \"${{ secrets.TF_VAR_BITBUCKET_LICENSE }}\"\n OPENSHIFT_PULL_SECRET: \"${{ secrets.OPENSHIFT_PULL_SECRET }}\"\n\n bamboo:\n uses: ./.github/workflows/openshift.yaml\n with:\n dc_app: bamboo\n secrets:\n BAMBOO_LICENSE: \"${{ secrets.TF_VAR_BAMBOO_LICENSE }}\"\n OPENSHIFT_PULL_SECRET: \"${{ secrets.OPENSHIFT_PULL_SECRET }}\"\n\n crowd:\n uses: ./.github/workflows/openshift.yaml\n with:\n dc_app: crowd\n secrets:\n OPENSHIFT_PULL_SECRET: \"${{ secrets.OPENSHIFT_PULL_SECRET }}\"\n" }, { "path": ".github/workflows/dc-tests.yml", "content": "# This workflow is for testing Helm charts in KinD clusters\n\nname: DC apps tests in KinD\n\non:\n schedule:\n - cron: '0 3 */2 * *' # schedule the test to run every second day at 3:00am\n push:\n branches:\n - main\n paths:\n - 'src/main/charts/bamboo/**'\n - 'src/main/charts/bamboo-agent/**'\n - 'src/main/charts/bitbucket/**'\n - 'src/main/charts/confluence/**'\n - 'src/main/charts/jira/**'\n - 'src/main/charts/crowd/**'\n workflow_dispatch:\n pull_request_target:\n types: [ labeled ]\n\njobs:\n jira:\n uses: ./.github/workflows/kind.yaml\n with:\n dc_app: jira\n secrets:\n JIRA_LICENSE: \"${{ secrets.JIRA_LICENSE }}\"\n\n confluence:\n uses: ./.github/workflows/kind.yaml\n with:\n dc_app: confluence\n secrets:\n CONFLUENCE_LICENSE: \"${{ secrets.TF_VAR_CONFLUENCE_LICENSE }}\"\n\n bitbucket:\n uses: ./.github/workflows/kind.yaml\n with:\n dc_app: bitbucket\n secrets:\n BITBUCKET_LICENSE: \"${{ secrets.TF_VAR_BITBUCKET_LICENSE }}\"\n\n bamboo:\n uses: ./.github/workflows/kind.yaml\n with:\n dc_app: bamboo\n secrets:\n BAMBOO_LICENSE: \"${{ secrets.TF_VAR_BAMBOO_LICENSE }}\"\n\n crowd:\n uses: ./.github/workflows/kind.yaml\n with:\n dc_app: crowd\n" }, { "path": ".github/workflows/documentation-build.yaml", "content": "name: Documentation - Build\non:\n pull_request:\njobs:\n deploy:\n runs-on: ubuntu-24.04\n steps:\n - uses: actions/checkout@v4\n - uses: actions/setup-python@v5\n with:\n python-version: 3.x\n - name: Install mkdocs requirements\n run: pip install -r requirements.txt\n working-directory: docs\n - name: Publish documentation to gp-pages branch\n run: mkdocs build\n working-directory: docs\n" }, { "path": ".github/workflows/documentation-deploy.yaml", "content": "name: Documentation - Deploy\non:\n push:\n branches:\n - main\njobs:\n deploy:\n runs-on: ubuntu-24.04\n steps:\n - uses: actions/checkout@v4\n - uses: actions/setup-python@v5\n with:\n python-version: 3.x\n - name: Install mkdocs requirements\n run: pip install -r requirements.txt\n working-directory: docs\n - name: Publish documentation to gp-pages branch\n run: mkdocs gh-deploy --force\n working-directory: docs\n" }, { "path": ".github/workflows/e2e-tf-deployment.yaml", "content": "name: Helm Charts E2E Testing\non:\n schedule:\n - cron: '0 3 */2 * *' # schedule the test to run every second day at 3:00am\n push:\n branches:\n - main\n paths:\n - 'src/main/charts/bamboo/**'\n - 'src/main/charts/bamboo-agent/**'\n - 'src/main/charts/bitbucket/**'\n - 'src/main/charts/confluence/**'\n - 'src/main/charts/jira/**'\n - 'src/main/charts/crowd/**'\n pull_request_target:\n types: [ labeled ]\n workflow_dispatch:\n inputs:\n use_gateway_api:\n description: 'Use Gateway API (Envoy Gateway) instead of NGINX Ingress'\n required: false\n type: boolean\n default: false\n terraform_branch:\n description: 'Terraform repo branch to use (leave empty for latest LTS tag)'\n required: false\n type: string\n default: ''\n\njobs:\n test:\n if: ${{ github.event.label.name == 'e2e' || github.event_name == 'push' || github.event_name == 'workflow_dispatch' || github.event_name == 'schedule' }}\n name: Deploy Infrastructure and Run E2E Tests\n runs-on: ubuntu-24.04\n permissions:\n id-token: write\n contents: read\n env:\n AWS_DEFAULT_REGION: us-east-1\n TF_VAR_bamboo_license: ${{ secrets.TF_VAR_BAMBOO_LICENSE }}\n TF_VAR_confluence_license: ${{ secrets.TF_VAR_CONFLUENCE_LICENSE }}\n TF_VAR_bitbucket_license: ${{ secrets.TF_VAR_BITBUCKET_LICENSE }}\n TF_VAR_crowd_license: ${{ secrets.TF_VAR_CROWD_LICENSE }}\n TF_VAR_bamboo_admin_password: ${{ secrets.TF_VAR_BAMBOO_ADMIN_PASSWORD }}\n TF_VAR_crowd_admin_password: ${{ secrets.TF_VAR_CROWD_ADMIN_PASSWORD }}\n TF_VAR_bitbucket_admin_password: ${{ secrets.TF_VAR_BITBUCKET_ADMIN_PASSWORD }}\n TF_VAR_kinesis_log_producers_role_arns: ${{ secrets.TF_VAR_KINESIS_LOG_PRODUCERS_ROLE_ARNS }}\n TF_VAR_osquery_fleet_enrollment_secret_name: ${{ secrets.TF_VAR_OSQUERY_FLEET_ENROLLMENT_SECRET_NAME }}\n TF_VAR_osquery_fleet_entrollment_host: ${{ secrets.TF_VAR_OSQUERY_FLEET_ENROLLMENT_HOST }}\n TF_VAR_crowdstrike_secret_name: ${{ secrets.TF_VAR_CROWDSTRIKE_SECRET_NAME }}\n TF_VAR_crowdstrike_kms_key_name: ${{ secrets.TF_VAR_CROWDSTRIKE_KMS_KEY_NAME }}\n TF_VAR_crowdstrike_aws_account_id: ${{ secrets.TF_VAR_CROWDSTRIKE_AWS_ACCOUNT_ID }}\n USE_DOMAIN: \"true\"\n USE_GATEWAY_API: ${{ github.event.inputs.use_gateway_api || 'false' }}\n\n steps:\n - name: Checkout Helm charts\n uses: actions/checkout@v4\n with:\n fetch-depth: 0\n ref: ${{ github.event.pull_request.head.sha }}\n\n - name: Install the latest Terraform\n run: |\n # check existing version\n terraform -version || true\n # download the latest\n URL=$(curl -fsSL https://api.releases.hashicorp.com/v1/releases/terraform/latest | jq -r '.builds[] | select((.arch==\"amd64\") and (.os==\"linux\")).url')\n curl -s -o /tmp/terraform.zip ${URL}\n echo A | unzip /tmp/terraform.zip -d /usr/local/bin/\n rm /tmp/terraform.zip \n # check the latest version\n terraform -version\n\n - name: Pin Kubectl version\n uses: azure/setup-kubectl@v3.0\n with:\n version: 'v1.30.0'\n\n - name: Install Helm\n uses: azure/setup-helm@v1\n with:\n version: v3.15.3\n\n - name: Execute helm dependency update for Helm charts\n run: |\n helm dependency update src/main/charts/bamboo\n helm dependency update src/main/charts/bamboo-agent\n helm dependency update src/main/charts/bitbucket\n helm dependency update src/main/charts/confluence\n helm dependency update src/main/charts/jira\n helm dependency update src/main/charts/crowd\n\n - name: Checkout Deployment Automation\n run: |\n DEPLOYMENT_REPO='https://github.com/atlassian-labs/data-center-terraform.git'\n CUSTOM_BRANCH=\"${{ github.event.inputs.terraform_branch }}\"\n if [ -n \"$CUSTOM_BRANCH\" ]; then\n echo \"Using custom branch '${CUSTOM_BRANCH}' of Deployment Automation.\"\n git clone -b $CUSTOM_BRANCH $DEPLOYMENT_REPO tf\n else\n LTS=$(git ls-remote --tags --exit-code --refs \"$DEPLOYMENT_REPO\" \\\n | sed -E 's/^[[:xdigit:]]+[[:space:]]+refs\\/tags\\/(.+)/\\1/g' \\\n | grep '^[0-9]*.[0-9]*.[0-9]*$' | sort -V | tail -1)\n echo \"Using LTS version('${LTS}') of Deployment Automation to provision the infrastructure for Atlassian DC Products.\"\n git clone -b $LTS $DEPLOYMENT_REPO tf\n fi\n\n - name: Setup test environment\n uses: actions/setup-go@v3\n with:\n go-version: '1.18'\n\n - name: Setup Python environment\n uses: actions/setup-python@v5\n with:\n python-version: '3.9.14'\n - run: |\n python -m pip install --upgrade pip\n pip install boto3\n\n - name: Install test dependencies\n id: setup-dependencies\n working-directory: tf/test/\n run: |\n go version\n go get -v -t -d ./... && go mod tidy\n echo ::set-output name=exit_code::$?\n\n - name: Add private SSH key for Bitbucket tests\n uses: shimataro/ssh-key-action@v2\n with:\n key: ${{ secrets.BITBUCKET_E2E_TEST_PRIV_SSH_KEY }}\n name: bitbucket-e2e # optional\n known_hosts: dummy-entry\n if_key_exists: fail # replace / ignore / fail; optional (defaults to fail)\n\n - name: Add public SSH key for Bitbucket tests\n run: |\n echo ${{ secrets.BITBUCKET_E2E_TEST_PUB_SSH_KEY }} > /home/runner/.ssh/bitbucket-e2e.pub\n\n - name: Configure AWS Credentials\n uses: aws-actions/configure-aws-credentials@master\n with:\n aws-region: us-east-1\n role-to-assume: ${{ secrets.AWS_IAM_ROLE }}\n role-session-name: DCTerraformHelmSession\n role-duration-seconds: 7200\n\n - name: Deploy the infrastructure, install helm charts, run E2E tests, and cleanup\n id: e2e-test\n working-directory: tf/test/\n run: |\n set -o pipefail\n # Create test output directory\n mkdir e2etest/artifacts\n\n # Add root of helm chart repo to the config template\n cat << EOF >> ./e2etest/test-config.tfvars.tmpl\n # install local helm charts\n local_helm_charts_path=\"$(dirname $(dirname $(pwd)))/src/main/charts\"\n confluence_install_local_chart = true\n jira_install_local_chart = true\n bitbucket_install_local_chart = true\n bamboo_install_local_chart = true\n crowd_install_local_chart = true\n EOF\n\n # Append Gateway API toggle if enabled\n if [ \"$USE_GATEWAY_API\" = \"true\" ]; then\n echo 'use_gateway_api = true' >> ./e2etest/test-config.tfvars.tmpl\n echo \"Gateway API mode enabled (Envoy Gateway will replace NGINX Ingress)\"\n else\n echo \"NGINX Ingress mode (default)\"\n fi\n\n # Deploy infrastructure, install helm charts, run e2e tests, and cleanup all\n # boto3 ignores AWS creds env vars for some reason\n mkdir -p ~/.aws\n echo -e \"[default]\\naws_access_key_id = ${AWS_ACCESS_KEY_ID}\\naws_secret_access_key = ${AWS_SECRET_ACCESS_KEY}\\naws_session_token = ${AWS_SESSION_TOKEN}\" > ~/.aws/credentials\n go test ./e2etest -v -timeout 85m -run Installer | tee ./e2etest/artifacts/e2etest.log\n\n - name: Upload test log files\n if: always()\n uses: actions/upload-artifact@v4\n with:\n name: e2e-test-artifacts\n path: tf/test/e2etest/artifacts/\n" }, { "path": ".github/workflows/kind.yaml", "content": "name: Test DC App in a KinD Cluster\n\non:\n workflow_call:\n inputs:\n dc_app:\n required: true\n type: string\n secrets:\n BITBUCKET_LICENSE:\n description: 'Bitbucket license'\n CONFLUENCE_LICENSE:\n description: 'Confluence license'\n JIRA_LICENSE:\n description: 'Jira license'\n BAMBOO_LICENSE:\n description: 'Bamboo license'\n\njobs:\n kind-testing:\n if: ${{ github.event.label.name == 'e2e' || github.event_name == 'push' || github.event_name == 'workflow_dispatch' || github.event_name == 'schedule' }}\n runs-on: ubuntu-24.04\n env:\n # See: https://github.com/kubernetes-sigs/kind/tags\n KIND_VERSION: \"v0.27.0\"\n # See: https://hub.docker.com/r/kindest/node/tags\n K8S_VERSION: \"v1.32.2\"\n DC_APP: ${{inputs.dc_app}}\n LICENSE: ${{ secrets[format('{0}_LICENSE', inputs.dc_app)] }}\n\n steps:\n - name: Checkout code\n uses: actions/checkout@v4\n with:\n fetch-depth: 0\n ref: ${{ github.event.pull_request.head.sha }}\n\n - name: Pin Kubectl version\n uses: azure/setup-kubectl@v4\n with:\n version: 'v1.32.2'\n\n - name: Pin Helm version\n uses: azure/setup-helm@v3\n with:\n version: v3.17.2\n\n - name: Create KinD cluster\n run: |\n src/test/scripts/kind/create_kind.sh\n\n - name: Install KinD tooling\n run: |\n src/test/scripts/kind/configure_kind.sh\n\n - name: Deploy postgres database\n run: |\n source src/test/scripts/kind/deploy_app.sh\n deploy_postgres\n\n - name: Create db, admin and license secrets\n run: |\n source src/test/scripts/kind/deploy_app.sh\n create_secrets\n\n - name: Deploy ${{inputs.dc_app}}\n run: |\n source src/test/scripts/kind/deploy_app.sh\n deploy_app\n\n - name: Verify ${{inputs.dc_app}} status\n run: |\n source src/test/scripts/kind/deploy_app.sh\n verify_gateway_ingress\n\n - name: Verify ${{inputs.dc_app}} grafana dashboards\n run: |\n source src/test/scripts/kind/deploy_app.sh\n verify_dashboards\n\n - name: Test scaling ${{inputs.dc_app}}\n run: |\n echo \"[INFO]: Scaling ${DC_APP} to 2 replicas\"\n kubectl scale sts/${DC_APP} --replicas=2 -n atlassian\n sleep 10\n kubectl wait --for=condition=ready pod/${DC_APP}-1 -n atlassian --timeout=360s\n\n - name: Verify ${{inputs.dc_app}} OpenSearch integration\n run: |\n source src/test/scripts/kind/deploy_app.sh\n verify_opensearch\n\n - name: Verify ${{inputs.dc_app}} metrics availability\n run: |\n source src/test/scripts/kind/deploy_app.sh\n verify_metrics\n\n - name: Verify Gateway API integration\n run: |\n source src/test/scripts/kind/deploy_app.sh\n verify_gateway\n\n - name: Get debug info\n if: always()\n run: |\n curl -s https://raw.githubusercontent.com/atlassian-labs/data-center-terraform/main/scripts/collect_k8s_logs.sh | bash -s -- dummy dummy logs/${{inputs.dc_app}}\n\n - name: Upload test log files\n if: always()\n uses: actions/upload-artifact@v4\n with:\n name: kind-artifacts-${{inputs.dc_app}}\n path: logs/\n" }, { "path": ".github/workflows/maven.yml", "content": "# This workflow will build a Java project with Maven\n# For more information see: https://help.github.com/actions/language-and-framework-guides/building-and-testing-java-with-maven\n\nname: Maven unit tests\n\non:\n push:\n branches:\n - main\n - /.*-stable/\n pull_request:\n\njobs:\n build:\n\n runs-on: ubuntu-24.04\n\n steps:\n - uses: actions/checkout@v4\n - name: Set up JDK 11\n uses: actions/setup-java@v1\n with:\n java-version: 11\n\n - name: Install Helm\n uses: azure/setup-helm@v3\n with:\n version: v3.15.3\n\n - name: Execute helm dependency update for bamboo chart\n run: helm dependency update src/main/charts/bamboo\n - name: Execute helm dependency update for bamboo-agent chart\n run: helm dependency update src/main/charts/bamboo-agent\n - name: Execute helm dependency update for bitbucket chart\n run: helm dependency update src/main/charts/bitbucket\n - name: Execute helm dependency update for confluence chart\n run: helm dependency update src/main/charts/confluence\n - name: Execute helm dependency update for crowd chart\n run: helm dependency update src/main/charts/crowd\n - name: Execute helm dependency update for jira chart\n run: helm dependency update src/main/charts/jira\n\n - name: Run tests with Maven\n run: mvn -B test\n" }, { "path": ".github/workflows/openshift.yaml", "content": "name: MicroShift Tests\n\non:\n workflow_call:\n inputs:\n dc_app:\n required: true\n type: string\n secrets:\n BITBUCKET_LICENSE:\n description: 'Bitbucket license'\n CONFLUENCE_LICENSE:\n description: 'Confluence license'\n JIRA_LICENSE:\n description: 'Jira license'\n BAMBOO_LICENSE:\n description: 'Bamboo license'\n OPENSHIFT_PULL_SECRET:\n description: 'OpenShift Pull Secret'\n\njobs:\n microshift:\n if: ${{ github.event.label.name == 'e2e' || github.event_name == 'push' || github.event_name == 'workflow_dispatch' || github.event_name == 'schedule' }}\n runs-on: ubuntu-24.04\n env:\n DC_APP: ${{inputs.dc_app}}\n LICENSE: ${{ secrets[format('{0}_LICENSE', inputs.dc_app)] }}\n OPENSHIFT_PULL_SECRET: ${{ secrets.OPENSHIFT_PULL_SECRET }}\n KUBECONFIG: /home/runner/.crc/machines/crc/kubeconfig\n\n steps:\n - name: Checkout\n uses: actions/checkout@v4\n with:\n fetch-depth: 0\n\n - name: Write pull secret file\n run: |\n echo \"${OPENSHIFT_PULL_SECRET}\" | base64 -d > pull-secret.txt\n\n - name: Fetch crc binary\n run: |\n CRC_VERSION=\"2.49.0\"\n wget -q https://developers.redhat.com/content-gateway/file/pub/openshift-v4/clients/crc/${CRC_VERSION}/crc-linux-amd64.tar.xz\n tar -xvf crc-linux-amd64.tar.xz\n sudo cp crc-linux-${CRC_VERSION}-amd64/crc /usr/bin/crc\n sudo chmod a+x /usr/bin/crc\n\n - name: Fetch oc binary\n run: |\n wget -q https://mirror.openshift.com/pub/openshift-v4/clients/ocp/stable-4.18/openshift-client-linux.tar.gz\n tar -xvf openshift-client-linux.tar.gz\n sudo cp oc /usr/bin/oc\n sudo chmod a+x /usr/bin/oc\n\n - name: Install required virtualization software\n run: |\n sudo apt-get update\n sudo apt install qemu-kvm libvirt-daemon libvirt-daemon-system virtiofsd\n sudo usermod -a -G libvirt $USER\n\n - name: Free up disk\n run: |\n sudo rm -rf /usr/share/dotnet\n sudo rm -rf /usr/local/lib/android\n sudo rm -rf /opt/ghc\n sudo rm -rf \"/usr/local/share/boost\"\n sudo rm -rf /opt/hostedtoolcache/CodeQL\n sudo docker image prune --all --force\n sudo swapoff -a\n sudo rm -f /mnt/swapfile\n\n - name: Set crc config and microshift profile\n run: |\n crc config set consent-telemetry no\n crc config set network-mode user\n crc config set preset microshift\n\n - name: Setup the crc\n run: sudo -su $USER crc setup\n\n - name: Start MicroShift\n run: sudo -su $USER crc start -p pull-secret.txt --log-level debug\n\n - name: Create atlassian namespace\n run: |\n oc create namespace atlassian\n\n - name: Grant anyuid SCC for the default service account\n run: |\n SCC=(\"anyuid\")\n for i in ${SCC[@]} ; do\n oc adm policy add-scc-to-user ${i} system:serviceaccount:atlassian:default\n done\n\n - name: Create shared home pvc\n run: |\n oc apply -f src/test/config/openshift/shared-home-pvc.yaml\n\n - name: Install Gateway API + Envoy Gateway\n run: |\n # Gateway API CRDs\n oc apply -f https://github.com/kubernetes-sigs/gateway-api/releases/download/v1.2.1/standard-install.yaml\n oc apply --server-side=true -f https://raw.githubusercontent.com/envoyproxy/gateway/v1.2.5/charts/gateway-helm/crds/generated/gateway.envoyproxy.io_envoyproxies.yaml\n \n oc wait --for condition=established --timeout=60s crd/gateways.gateway.networking.k8s.io\n oc wait --for condition=established --timeout=60s crd/httproutes.gateway.networking.k8s.io\n oc wait --for condition=established --timeout=60s crd/gatewayclasses.gateway.networking.k8s.io\n oc wait --for condition=established --timeout=60s crd/envoyproxies.gateway.envoyproxy.io\n\n # Envoy Gateway (installs into envoy-gateway-system)\n # OpenShift admission can reject fixed runAsUser/seccomp settings unless the\n # service accounts are allowed to use a more permissive SCC.\n oc create namespace envoy-gateway-system --dry-run=client -o yaml | oc apply -f -\n # Pre-grant SCCs to all service accounts in the namespace so Helm hooks can run\n # even before the chart-created ServiceAccounts exist.\n oc adm policy add-scc-to-group anyuid system:serviceaccounts:envoy-gateway-system || true\n oc adm policy add-scc-to-group privileged system:serviceaccounts:envoy-gateway-system || true\n\n helm install eg oci://docker.io/envoyproxy/gateway-helm \\\n --version v1.2.5 \\\n --namespace envoy-gateway-system \\\n --set deployment.envoyGateway.resources.requests.cpu=50m \\\n --set deployment.envoyGateway.resources.requests.memory=100Mi \\\n --skip-crds \\\n --timeout=600s \\\n --wait || { \\\n oc get all -n envoy-gateway-system || true; \\\n oc get events -n envoy-gateway-system --sort-by='.lastTimestamp' | tail -n 200 || true; \\\n exit 1; \\\n }\n\n oc wait --for=condition=available deployment/envoy-gateway \\\n --namespace envoy-gateway-system \\\n --timeout=300s\n\n # EnvoyProxy CR configures the proxy Service as ClusterIP (default for OpenShift; an OpenShift Route will handle external access).\n oc apply -f src/test/config/openshift/envoy-proxy.yaml\n \n # GatewayClass references the EnvoyProxy CR via parametersRef\n cat << EOF | oc apply -f -\n apiVersion: gateway.networking.k8s.io/v1\n kind: GatewayClass\n metadata:\n name: eg\n spec:\n controllerName: gateway.envoyproxy.io/gatewayclass-controller\n parametersRef:\n group: gateway.envoyproxy.io\n kind: EnvoyProxy\n name: openshift-proxy-config\n namespace: envoy-gateway-system\n EOF\n oc wait --for=condition=Accepted gatewayclass/eg --timeout=180s || { oc get gatewayclass/eg -o yaml; oc get pods -n envoy-gateway-system -o wide || true; exit 1; }\n\n # Create test Gateway\n oc apply -f src/test/config/openshift/gateway.yaml\n oc wait --for=condition=Accepted gateway/atlassian-gateway -n atlassian --timeout=300s || { oc describe gateway/atlassian-gateway -n atlassian; oc get events -n atlassian --sort-by='.lastTimestamp' | tail -n 200 || true; exit 1; }\n\n # Wait for data-plane\n oc wait --for=condition=Available deployment \\\n -n envoy-gateway-system \\\n -l gateway.envoyproxy.io/owning-gateway-name=atlassian-gateway \\\n --timeout=300s || { \\\n oc get deployments -n envoy-gateway-system -o wide; \\\n oc get pods -n envoy-gateway-system -o wide; \\\n oc describe deployment -n envoy-gateway-system -l gateway.envoyproxy.io/owning-gateway-name=atlassian-gateway || true; \\\n oc get events -n envoy-gateway-system --sort-by='.lastTimestamp' | tail -n 200 || true; \\\n exit 1; \\\n }\n\n # Create an OpenShift Route so atlassian.apps.crc.testing reaches the\n # Envoy proxy Service without port-forward or Host headers.\n ENVOY_SVC=$(oc get svc -n envoy-gateway-system \\\n -l gateway.envoyproxy.io/owning-gateway-name=atlassian-gateway \\\n -o jsonpath='{.items[0].metadata.name}' 2>/dev/null || true)\n\n if [ -z \"${ENVOY_SVC}\" ]; then\n echo \"[ERROR]: Envoy Gateway proxy service not found\"\n oc get svc -n envoy-gateway-system -o wide || true\n exit 1\n fi\n\n oc -n envoy-gateway-system expose svc/${ENVOY_SVC} \\\n --name atlassian-gateway-proxy \\\n --hostname atlassian.apps.crc.testing || true\n\n # Log the Route and Endpoint details for debugging\n oc -n envoy-gateway-system get route atlassian-gateway-proxy -o yaml || true\n oc -n envoy-gateway-system get endpoints ${ENVOY_SVC} -o yaml || true\n\n - name: Deploy postgres database\n run: |\n source src/test/scripts/kind/deploy_app.sh\n deploy_postgres\n\n - name: Create db, admin and license secrets\n run: |\n source src/test/scripts/kind/deploy_app.sh\n create_secrets\n\n - name: Deploy ${{inputs.dc_app}}\n run: |\n export OPENSHIFT_VALUES=\"-f ./src/test/config/openshift/openshift.yaml --set ${DC_APP}.resources.container.requests.cpu=20m --set ${DC_APP}.resources.container.requests.memory=5Mi --set synchrony.resources.container.requests.cpu=20m --set synchrony.resources.container.requests.memory=5Mi\"\n source src/test/scripts/kind/deploy_app.sh\n deploy_app\n\n - name: Verify ${{inputs.dc_app}} status\n run: |\n export OPENSHIFT_VALUES=\"1\"\n source src/test/scripts/kind/deploy_app.sh\n verify_gateway_ingress\n\n - name: Verify ${{inputs.dc_app}} metrics availability\n run: |\n source src/test/scripts/kind/deploy_app.sh\n verify_metrics\n\n - name: Verify ${{inputs.dc_app}} analytics value\n run: |\n source src/test/scripts/kind/deploy_app.sh\n verify_openshift_analytics\n\n - name: Verify Gateway API integration\n run: |\n source src/test/scripts/kind/deploy_app.sh\n verify_gateway\n\n - name: Get debug info\n if: always()\n run: |\n curl -s https://raw.githubusercontent.com/atlassian-labs/data-center-terraform/main/scripts/collect_k8s_logs.sh | bash -s -- dummy dummy logs/${{inputs.dc_app}}\n\n - name: Upload test log files\n if: always()\n uses: actions/upload-artifact@v4\n with:\n name: kind-artifacts-${{inputs.dc_app}}\n path: logs/\n" }, { "path": ".github/workflows/prepare-release.yaml", "content": "name: Prepare Release\n\non:\n push:\n branches:\n - release/*\n\njobs:\n prepare-release:\n env:\n GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}\n runs-on: ubuntu-24.04\n\n steps:\n - name: Checkout code\n uses: actions/checkout@v4\n with:\n fetch-depth: 0\n ref: refs/heads/main\n\n - name: Set up JDK 11\n uses: actions/setup-java@v1\n with:\n java-version: 11\n\n - name: Install Helm\n uses: azure/setup-helm@v3\n with:\n version: v3.15.3\n\n - name: Setup Python environment\n uses: actions/setup-python@v5\n with:\n python-version: '3.9.14'\n\n - name: Install Python dependencies\n run: |\n python -m pip install --upgrade pip gitpython ruamel_yaml\n\n - name: Install Helm Docs\n uses: envoy/install-helm-docs@v1.0.0\n with:\n version: 1.12.0\n\n - name: Generate changelog and Chart annotations\n run: |\n echo \"[INFO]: Preparing release ${GITHUB_REF_NAME##*/}\"\n python src/main/scripts/prepare_release.py ${GITHUB_REF_NAME##*/}\n\n - name: Update README files with helm-docs\n run: |\n cd src/main/charts\n helm-docs\n\n - name: Configure Git\n run: |\n git config --global user.name \"$GITHUB_ACTOR\"\n git config --global user.email \"$GITHUB_ACTOR@users.noreply.github.com\"\n\n - name: Lint yamls with ah cli\n run: |\n docker run --workdir=\"/charts\" -u root -v ${GITHUB_WORKSPACE}/src/main/charts:/charts artifacthub/ah ah lint\n\n - name: Commit changes and raise a PR\n run: |\n git checkout ${GITHUB_REF_NAME}\n git add -A\n git commit -m \"Prepare release ${GITHUB_REF_NAME##*/}\"\n git push origin ${GITHUB_REF_NAME}\n gh pr create --title \"Release/${GITHUB_REF_NAME##*/}\" --body \"Prepare to release ${GITHUB_REF_NAME##*/}\" --base main --head ${GITHUB_REF_NAME}\n" }, { "path": ".github/workflows/process-dashboard-test.yaml", "content": "name: Process Dashboard Script Testing\n\non:\n push:\n paths:\n - 'src/main/scripts/process_dash*'\n workflow_dispatch:\n\njobs:\n run-process-dashboard-tests:\n runs-on: ubuntu-24.04\n\n steps:\n - name: Checkout code\n uses: actions/checkout@v4\n with:\n fetch-depth: 0\n\n - name: Setup Python environment\n uses: actions/setup-python@v5\n with:\n python-version: '3.9.14'\n\n - name: Run tests\n run: |\n python src/main/scripts/process_dashboard_test.py\n" }, { "path": ".github/workflows/release-charts.yaml", "content": "name: Release Helm Charts\n\non:\n workflow_dispatch:\n\njobs:\n release:\n runs-on: ubuntu-24.04\n permissions:\n id-token: write\n contents: write\n pull-requests: write\n env:\n GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}\n HELM_SIGNING_KEY_ID: ${{ secrets.HELM_SIGNING_KEY_ID }}\n GITHUB_REPOSITORY: ${GITHUB_REPOSITORY}\n steps:\n - name: Checkout\n uses: actions/checkout@v4\n with:\n fetch-depth: 0\n\n - name: Configure Git\n run: |\n git config user.name \"$GITHUB_ACTOR\"\n git config user.email \"$GITHUB_ACTOR@users.noreply.github.com\"\n\n - name: Install Helm\n uses: azure/setup-helm@v3\n with:\n version: v3.15.3\n\n - name: Setup Python environment\n uses: actions/setup-python@v5\n with:\n python-version: '3.9.14'\n\n - name: Install Python dependencies\n run: |\n python -m pip install --upgrade pip gitpython ruamel_yaml\n\n - name: Generate Release Notes for GitHub Releases\n run: |\n cd src/main/scripts\n products=(bamboo bamboo-agent bitbucket confluence crowd jira)\n export REPO_PATH=\"${GITHUB_WORKSPACE}\"\n export CHARTS_LOCATION=\"src/main/charts\"\n for product in \"${products[@]}\"; do\n echo \"[INFO]: Generating ${REPO_PATH}/${CHARTS_LOCATION}/${product}/RELEASE_NOTES.md\"\n REL_NOTES_LIST=$(python3 -W ignore -c \"import prepare_release; print (prepare_release.gen_changelog(\\\"${product}\\\", \\\"${REPO_PATH}\\\"))\")\n python -c \"list=${REL_NOTES_LIST}; print('\\n'.join(list))\" > \"${REPO_PATH}\"/\"${CHARTS_LOCATION}\"/\"${product}\"/RELEASE_NOTES.md\n done\n\n - name: Execute helm dependency update for bamboo chart\n run: helm dependency update src/main/charts/bamboo\n - name: Execute helm dependency update for bamboo-agent chart\n run: helm dependency update src/main/charts/bamboo-agent\n - name: Execute helm dependency update for bitbucket chart\n run: helm dependency update src/main/charts/bitbucket\n - name: Execute helm dependency update for confluence chart\n run: helm dependency update src/main/charts/confluence\n - name: Execute helm dependency update for crowd chart\n run: helm dependency update src/main/charts/crowd\n - name: Execute helm dependency update for jira chart\n run: helm dependency update src/main/charts/jira\n\n\n - name: Configure AWS Credentials\n uses: aws-actions/configure-aws-credentials@master\n with:\n aws-region: ${{ secrets.HELM_SIGNING_KEY_AWS_REGION }}\n role-to-assume: ${{ secrets.HELM_SIGNING_KEY_AWS_IAM_ROLE }}\n role-session-name: HelmSignSession\n\n - name: Get Helm Signing Key\n run: |\n aws secretsmanager get-secret-value --secret-id ${{ secrets.HELM_SIGNING_KEY_AWS_SECRET_ID }} --query 'SecretBinary' --output text --region ${{ secrets.HELM_SIGNING_KEY_AWS_REGION }} | base64 --decode > helm_key\n gpg --import helm_key\n gpg --export > ~/.gnupg/pubring.gpg\n gpg --export-secret-keys > ~/.gnupg/secring.gpg\n gpg --output src/main/scripts/helm_key.pub --export ${{ secrets.HELM_SIGNING_KEY_EMAIL }}\n\n - name: Release Helm Charts\n run: |\n src/main/scripts/generate_chart_repo.sh ${GH_TOKEN}\n\n - name: Commit and push index.yaml\n run: |\n git checkout -b update-index-yaml-${GITHUB_RUN_ID}\n git commit -m \"Update index.yaml post release\"\n git push origin update-index-yaml-${GITHUB_RUN_ID}\n gh pr create --title \"Update index.yaml\" --body \"Update index.yaml after release\" --base main --head update-index-yaml-${GITHUB_RUN_ID}\n\n - name: Upload Public Key To Release Assets\n run: |\n cd src/main/scripts\n export RELEASE_VERSION=$(python3 -W ignore -c \"import prepare_release; print (prepare_release.get_chart_versions(\\\"${GITHUB_WORKSPACE}/src/main/charts\\\"))\" | sed \"s/'/\\\"/g\" | python -c 'import sys, json; print (json.load(sys.stdin)[\"bamboo\"][\"version\"])')\n ./github_asset_uploader.sh ${RELEASE_VERSION}\n\n - name: Cleanup\n if: always()\n run: |\n rm -rf ~/.gnupg || true\n rm -rf helm_key\n" }, { "path": ".github/workflows/release-unit-tests.yaml", "content": "name: Release Script Unit Testing\n\non:\n push:\n paths:\n - 'src/main/scripts/prepare_*'\n workflow_dispatch:\n\njobs:\n run-release-unit-tests:\n runs-on: ubuntu-24.04\n\n steps:\n - name: Checkout code\n uses: actions/checkout@v4\n with:\n fetch-depth: 0\n\n - name: Setup Python environment\n uses: actions/setup-python@v5\n with:\n python-version: '3.9.14'\n\n - name: Install Python dependencies\n run: |\n python -m pip install --upgrade pip gitpython ruamel_yaml\n\n - name: Run release unit tests\n run: |\n python src/main/scripts/prepare_release_test.py\n" }, { "path": ".github/workflows/sync-grafana-dashboards.yaml", "content": "name: Update Grafana Dashboards\n\non:\n schedule:\n - cron: '0 1 * * SUN' # At 1AM on every Sunday\n workflow_dispatch:\n\njobs:\n sync_dashboards:\n runs-on: ubuntu-24.04\n env:\n GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}\n steps:\n - name: Checkout\n uses: actions/checkout@v4\n with:\n fetch-depth: 0\n\n - name: Setup Python environment\n uses: actions/setup-python@v5\n with:\n python-version: '3.9.14'\n\n - name: Configure Git\n run: |\n git config user.name \"$GITHUB_ACTOR\"\n git config user.email \"$GITHUB_ACTOR@users.noreply.github.com\"\n\n - name: Process Grafana Dashboards\n run: |\n src/main/scripts/update_grafana_dashboards.sh\n \n - name: Commit changes and raise a PR\n run: |\n CHANGES=$(git status --porcelain=v1 2>/dev/null | wc -l)\n if [ ${CHANGES} -ne 0 ]; then\n OPEN_PRS=$(gh pr list --state open | grep \"Update Grafana Dashboards for DC apps\" || true)\n if [[ ${OPEN_PRS} ]]; then\n echo \"Not raising PR because there are open PRs to update dashboards. Merge or close them to let the workflow raise new PRs\"\n else\n git checkout -b update-grafana-dashboards-${GITHUB_RUN_ID}\n git add -A\n git commit -m \"Update Grafana dashboards for DC apps\"\n git push origin update-grafana-dashboards-${GITHUB_RUN_ID}\n gh pr create --title \"Update Grafana Dashboards for DC apps\" --body \"Update Grafana dashboards for DC apps\" --base main --head update-grafana-dashboards-${GITHUB_RUN_ID}\n fi\n else\n echo \"All Helm charts have up to date Grafana dashboards\"\n fi\n" }, { "path": ".github/workflows/update-lts-tags.yaml", "content": "name: Update LTS Tags\n\non:\n workflow_dispatch:\n schedule:\n - cron: '0 0 * * SUN' # At 00:00 on every Sunday\n\njobs:\n lts_check:\n runs-on: ubuntu-24.04\n env:\n ARTIFACTORY_BOT_USERNAME: \"${{ secrets.ARTIFACTORY_BOT_USERNAME }}\"\n ARTIFACTORY_BOT_PASSWORD: \"${{ secrets.ARTIFACTORY_BOT_PASSWORD }}\"\n GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}\n steps:\n - name: Checkout\n uses: actions/checkout@v4\n with:\n fetch-depth: 0\n\n - name: Setup Python environment\n uses: actions/setup-python@v5\n with:\n python-version: '3.9.14'\n\n - name: Install dependencies\n run: |\n python -m pip install --upgrade pip\n pip install pyyaml requests\n\n - name: Install Helm Docs\n uses: envoy/install-helm-docs@v1.0.0\n with:\n version: 1.12.0\n\n - name: Configure Git\n run: |\n git config user.name \"$GITHUB_ACTOR\"\n git config user.email \"$GITHUB_ACTOR@users.noreply.github.com\"\n\n - name: Update LTS tags in Helm charts\n run: |\n cd src/test/scripts\n python update_versions.py\n\n - name: Update README files with helm-docs\n run: |\n cd src/main/charts\n helm-docs\n\n - name: Commit changes and raise a PR\n run: |\n CHANGES=$(git status --porcelain=v1 2>/dev/null | wc -l)\n if [ ${CHANGES} -ne 0 ]; then\n OPEN_PRS=$(gh pr list --state open | grep \"Update appVersions for DC apps\" || true)\n if [[ ${OPEN_PRS} ]]; then\n echo \"Not raising PR because there are open PRs to upgrade versions. Merge or close them to let the workflow raise new PRs\"\n else\n git checkout -b lts-tag-update-${GITHUB_RUN_ID}\n git add -A\n git commit -m \"Update appVersions for DC apps\"\n git push origin lts-tag-update-${GITHUB_RUN_ID}\n gh pr create --label \"e2e\" --title \"Update appVersions for DC apps\" --body \"Update appVersions for DC apps\" --base main --head lts-tag-update-${GITHUB_RUN_ID}\n fi\n else\n echo \"All Helm charts have the latest LTS appVersion\"\n fi\n" }, { "path": ".gitignore", "content": ".idea\n.vscode\n\ntarget\n__pycache__\n*.iml\n\\#*\\#\ndocs/site\ntmp\n.settings\n.project\n.classpath\n\n# ignore installed common library chart\nsrc/main/charts/*/charts/*.tgz\n\n# Stale tmpfile from failed release process\nsrc/main/charts/*/tmp*\n" }, { "path": ".java-version", "content": "11.0\n" }, { "path": ".pre-commit-config.yaml", "content": "repos:\n - repo: https://github.com/norwoodj/helm-docs\n rev: v1.12.0\n hooks:\n - id: helm-docs\n args:\n - --chart-search-root=src/main/charts\n\n # Repeating the flag adds this to the list, now [./_templates.gotmpl, README.md.gotmpl]\n # A base filename makes it relative to each chart directory found\n - --template-files=./README.md.gotmpl" }, { "path": "BREAKING_CHANGES.md", "content": "# Breaking Changes\n\n## Version 2.0.0\n\n### Required values\n\n* `.Values.bitbucket.clustering.group` is required for Bitbucket\n* `.Values.bitbucket.mirror` is required for Bitbucket\n* `.Values.bitbucket.podManagementStrategy` is required for Bitbucket\n* `.Values.ingress.className` is required for all products\n\n### `securityContext` format change\n`.Values..securityContext` is now fully configurable with standard [Kubernetes values](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/). \nIn order to make this happen, we removed `gid` and `enabled` fields from `securityContext` stanza in `values.yaml` file. \nInstead, the standard `fsGroup` value is now the default parameter to make ensure the correct filesystem permissions. This setting is not necessary in OpenShift (or some other specific use cases).\n\n#### Action required\n\n- If `.Values..securityContext.enabled` was set to `true` (the default value), set the existing `.Values..securityContext.gid` value to `.Values..securityContext.fsGroup`.\n- If `.Values..securityContext.enabled` was set to `false`, comment out all keys under `.Values..securityContext.securityContext` stanza. This means the `.Values..securityContext` should be empty.\n\n#### Troubleshooting\n\nIf you encounter this error:\n\n```\nError: unable to build kubernetes objects from release manifest: error validating \"\": error validating data: [ValidationError(StatefulSet.spec.template.spec.securityContext): unknown field \"enabled\" in io.k8s.api.core.v1.PodSecurityContext, ValidationError(StatefulSet.spec.template.spec.securityContext): unknown field \"gid\" in io.k8s.api.core.v1.PodSecurityContext]\n```\n\nIt means your `values.yaml` file contains the unsupported `enabled` or `gid` values for the `securityContext`. Please follow the steps from `securityContext` change above.\n\n### OpenSearch Credentials in Confluence Helm Chart\n\nOpenSearch credentials are now passed as environment variables instead of JVM arguments in the ConfigMap. This is a breaking change for existing Confluence Helm charts that use bundled OpenSearch (`opensearch.enabled` is set to true).\n\nIn **2.0.0** `-Dopensearch.password` has been removed from config-jvm ConfigMap. OpenSearch credentials and other relevant settings are now passed as environment variables and written to `confluence.cfg.xml` in the image entrypoint (See: [Add Opensearch properties](https://bitbucket.org/atlassian-docker/docker-atlassian-confluence-server/pull-requests/192/overview)).\n\nWhen upgrading Confluence Helm chart to version 2.0.0, you **must** set `confluence.forceConfigUpdate` to true in Helm values file, which will force the image entrypoint to recreate the `confluence.cfg.xml` file with the new Opensearch properties.\nThis is a one-time operation. After the upgrade, you can set `confluence.forceConfigUpdate` to false.\n" }, { "path": "CODE_OF_CONDUCT.md", "content": "# Contributor Code of Conduct\n\nAs contributors and maintainers of this project, and in the interest of fostering an open and welcoming community, we pledge to respect all people who contribute through reporting issues, posting feature requests, updating documentation, submitting pull requests or patches, and other activities.\n\nWe are committed to making participation in this project a harassment-free experience for everyone, regardless of level of experience, gender, gender identity and expression, sexual orientation, disability, personal appearance, body size, race, ethnicity, age, religion, or nationality.\n\nExamples of unacceptable behavior by participants include:\n\n* The use of sexualized language or imagery\n* Personal attacks\n* Trolling or insulting/derogatory comments\n* Public or private harassment\n* Publishing other's private information, such as physical or electronic addresses, without explicit permission\n* Submitting contributions or comments that you know to violate the intellectual property or privacy rights of others\n* Other unethical or unprofessional conduct\n\nProject maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, or to ban temporarily or permanently any contributor for other behaviors that they deem inappropriate, threatening, offensive, or harmful.\nBy adopting this Code of Conduct, project maintainers commit themselves to fairly and consistently applying these principles to every aspect of managing this project. Project maintainers who do not follow or enforce the Code of Conduct may be permanently removed from the project team.\n\nThis Code of Conduct applies both within project spaces and in public spaces when an individual is representing the project or its community.\n\nInstances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting a project maintainer. Complaints will result in a response and be reviewed and investigated in a way that is deemed necessary and appropriate to the circumstances. Maintainers are obligated to maintain confidentiality with regard to the reporter of an incident.\n\nThis Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.3.0, available at [http://contributor-covenant.org/version/1/3/0/][version]\n\n[homepage]: http://contributor-covenant.org\n[version]: http://contributor-covenant.org/version/1/3/0/" }, { "path": "CONTRIBUTING.md", "content": "# Contributing to Data Center Helm Charts\n\nThank you for considering a contribution to Data Center Helm Charts. Pull requests, issues and comments are welcome. For pull requests, please:\n\n* Add tests for new features and bug fixes\n* Follow the existing style\n* Separate unrelated changes into multiple pull requests\n\nFollow the [development setup](DEVELOPMENT.md).\n\nSee the existing issues for things to start contributing.\n\nFor bigger changes, please make sure you start a discussion first by creating an issue and explaining the intended change.\n\nAtlassian requires contributors to sign a Contributor License Agreement, known as a CLA. This serves as a record stating that the contributor is entitled to contribute the code/documentation/translation to the project and is willing to have it used in distributions and derivative works (or is willing to transfer ownership).\n\nPrior to accepting your contributions we ask that you please follow the appropriate link below to digitally sign the CLA. The Corporate CLA is for those who are contributing as a member of an organization and the individual CLA is for those contributing as an individual.\n\n* [CLA for corporate contributors](https://opensource.atlassian.com/corporate)\n* [CLA for individuals](https://opensource.atlassian.com/individual)\n\n## Code Owners' Responsibilities\n\nFor any pull requests, code owners should review the changes thoroughly and make sure all the requirements are met. Code owners should also run the internal Bamboo CI tests and E2E tests against the changes when are applicable.\n\nFor external contributions, any Github action workflow related changes are not acceptable.\n\n## Windows Users\n\nThis repository uses **symlinks** to share common Helm templates across product charts\n(see `src/main/common_templates/`). Git on Windows doesn't enable symlinks by default — without them,\nHelm template rendering will fail.\n\nTo enable symlinks on Windows:\n\n1. Enable **Developer Mode** in Windows Settings (Settings → Update & Security → For Developers), or run Git as Administrator\n2. Configure Git to create real symlinks:\n ```\n git config --global core.symlinks true\n ```\n3. Re-clone the repository after changing this setting (existing clones won't retroactively fix symlinks)\n\n\n### How to run E2E tests\n\nThe Data Center Helm Charts uses the latest release of [Deployment Automation for Atlassian DC on K8s](https://github.com/atlassian-labs/data-center-terraform#deployment-automation-for-atlassian-dc-on-k8s) for end-to-end testing. Internal reviewers can run the tests by adding `e2e` label on a pull request (for external contributions, be mindful of the changes as it will run on internal cloud environment)." }, { "path": "DEVELOPMENT.md", "content": "# Development\n\n## Chart dependencies\n\nProduct charts are using a common library chart (`common`). To download the dependency, you are required to run:\n\n```bash\nfor d in ./src/main/charts/*/ ; do (cd $d && helm dependency update); done\n```\n\n## Pre-commit hooks\n\nRepository contains repository hook definition to auto-generate chart documentation in case there is a change to `values.yaml` file.\n\n### Installation\n\n1. Install `pre-commit` following [official instructions](https://pre-commit.com/#install).\n2. In the repository root run `pre-commit install`, which will install the hooks.\n\n### Usage\n\nWhen you have the pre-commit hook installed and `commit` a file, it will run the pre-commit hook. If there is a change generated in the `README.md`, the hook will fail and notify you about the new change. You can review the changes and run the `commit` again, now it should pass.\n\n\n# Technical documentation\n\n## Setup\n\nTechnical documentation is produced by `mkdocs` python library. The documentation and necessary files are located in `/docs/` folder.\n\n## How to work with documentation\n\nTo make working with the documentation easier, there is a `Makefile` in the project root folder. To start the server just run:\n\n make docs\n\nThis will create a docker image locally, process the files and start the live server providing documentation. You should be able to open http://127.0.0.1:8000/ in your browser. If you make any change to the documentation in the `/docs/` folder, it will be picked up by the server and browser will automatically reload.\n\n## Deployment\n\nDocumentation is automatically deployed to [official documentation](https://atlassian.github.io/data-center-helm-charts/) with Github Pages. Any change that is merged into the default branch will trigger Github Actions that builds the static documentation site and pushes it to `gh-pages` branch. This branch is then deployed by Github Pages." }, { "path": "LICENSE", "content": " Apache License\n Version 2.0, January 2004\n http://www.apache.org/licenses/\n\n TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION\n\n 1. Definitions.\n\n \"License\" shall mean the terms and conditions for use, reproduction,\n and distribution as defined by Sections 1 through 9 of this document.\n\n \"Licensor\" shall mean the copyright owner or entity authorized by\n the copyright owner that is granting the License.\n\n \"Legal Entity\" shall mean the union of the acting entity and all\n other entities that control, are controlled by, or are under common\n control with that entity. For the purposes of this definition,\n \"control\" means (i) the power, direct or indirect, to cause the\n direction or management of such entity, whether by contract or\n otherwise, or (ii) ownership of fifty percent (50%) or more of the\n outstanding shares, or (iii) beneficial ownership of such entity.\n\n \"You\" (or \"Your\") shall mean an individual or Legal Entity\n exercising permissions granted by this License.\n\n \"Source\" form shall mean the preferred form for making modifications,\n including but not limited to software source code, documentation\n source, and configuration files.\n\n \"Object\" form shall mean any form resulting from mechanical\n transformation or translation of a Source form, including but\n not limited to compiled object code, generated documentation,\n and conversions to other media types.\n\n \"Work\" shall mean the work of authorship, whether in Source or\n Object form, made available under the License, as indicated by a\n copyright notice that is included in or attached to the work\n (an example is provided in the Appendix below).\n\n \"Derivative Works\" shall mean any work, whether in Source or Object\n form, that is based on (or derived from) the Work and for which the\n editorial revisions, annotations, elaborations, or other modifications\n represent, as a whole, an original work of authorship. For the purposes\n of this License, Derivative Works shall not include works that remain\n separable from, or merely link (or bind by name) to the interfaces of,\n the Work and Derivative Works thereof.\n\n \"Contribution\" shall mean any work of authorship, including\n the original version of the Work and any modifications or additions\n to that Work or Derivative Works thereof, that is intentionally\n submitted to Licensor for inclusion in the Work by the copyright owner\n or by an individual or Legal Entity authorized to submit on behalf of\n the copyright owner. For the purposes of this definition, \"submitted\"\n means any form of electronic, verbal, or written communication sent\n to the Licensor or its representatives, including but not limited to\n communication on electronic mailing lists, source code control systems,\n and issue tracking systems that are managed by, or on behalf of, the\n Licensor for the purpose of discussing and improving the Work, but\n excluding communication that is conspicuously marked or otherwise\n designated in writing by the copyright owner as \"Not a Contribution.\"\n\n \"Contributor\" shall mean Licensor and any individual or Legal Entity\n on behalf of whom a Contribution has been received by Licensor and\n subsequently incorporated within the Work.\n\n 2. Grant of Copyright License. Subject to the terms and conditions of\n this License, each Contributor hereby grants to You a perpetual,\n worldwide, non-exclusive, no-charge, royalty-free, irrevocable\n copyright license to reproduce, prepare Derivative Works of,\n publicly display, publicly perform, sublicense, and distribute the\n Work and such Derivative Works in Source or Object form.\n\n 3. Grant of Patent License. Subject to the terms and conditions of\n this License, each Contributor hereby grants to You a perpetual,\n worldwide, non-exclusive, no-charge, royalty-free, irrevocable\n (except as stated in this section) patent license to make, have made,\n use, offer to sell, sell, import, and otherwise transfer the Work,\n where such license applies only to those patent claims licensable\n by such Contributor that are necessarily infringed by their\n Contribution(s) alone or by combination of their Contribution(s)\n with the Work to which such Contribution(s) was submitted. If You\n institute patent litigation against any entity (including a\n cross-claim or counterclaim in a lawsuit) alleging that the Work\n or a Contribution incorporated within the Work constitutes direct\n or contributory patent infringement, then any patent licenses\n granted to You under this License for that Work shall terminate\n as of the date such litigation is filed.\n\n 4. Redistribution. You may reproduce and distribute copies of the\n Work or Derivative Works thereof in any medium, with or without\n modifications, and in Source or Object form, provided that You\n meet the following conditions:\n\n (a) You must give any other recipients of the Work or\n Derivative Works a copy of this License; and\n\n (b) You must cause any modified files to carry prominent notices\n stating that You changed the files; and\n\n (c) You must retain, in the Source form of any Derivative Works\n that You distribute, all copyright, patent, trademark, and\n attribution notices from the Source form of the Work,\n excluding those notices that do not pertain to any part of\n the Derivative Works; and\n\n (d) If the Work includes a \"NOTICE\" text file as part of its\n distribution, then any Derivative Works that You distribute must\n include a readable copy of the attribution notices contained\n within such NOTICE file, excluding those notices that do not\n pertain to any part of the Derivative Works, in at least one\n of the following places: within a NOTICE text file distributed\n as part of the Derivative Works; within the Source form or\n documentation, if provided along with the Derivative Works; or,\n within a display generated by the Derivative Works, if and\n wherever such third-party notices normally appear. The contents\n of the NOTICE file are for informational purposes only and\n do not modify the License. You may add Your own attribution\n notices within Derivative Works that You distribute, alongside\n or as an addendum to the NOTICE text from the Work, provided\n that such additional attribution notices cannot be construed\n as modifying the License.\n\n You may add Your own copyright statement to Your modifications and\n may provide additional or different license terms and conditions\n for use, reproduction, or distribution of Your modifications, or\n for any such Derivative Works as a whole, provided Your use,\n reproduction, and distribution of the Work otherwise complies with\n the conditions stated in this License.\n\n 5. Submission of Contributions. Unless You explicitly state otherwise,\n any Contribution intentionally submitted for inclusion in the Work\n by You to the Licensor shall be under the terms and conditions of\n this License, without any additional terms or conditions.\n Notwithstanding the above, nothing herein shall supersede or modify\n the terms of any separate license agreement you may have executed\n with Licensor regarding such Contributions.\n\n 6. Trademarks. This License does not grant permission to use the trade\n names, trademarks, service marks, or product names of the Licensor,\n except as required for reasonable and customary use in describing the\n origin of the Work and reproducing the content of the NOTICE file.\n\n 7. Disclaimer of Warranty. Unless required by applicable law or\n agreed to in writing, Licensor provides the Work (and each\n Contributor provides its Contributions) on an \"AS IS\" BASIS,\n WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or\n implied, including, without limitation, any warranties or conditions\n of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A\n PARTICULAR PURPOSE. You are solely responsible for determining the\n appropriateness of using or redistributing the Work and assume any\n risks associated with Your exercise of permissions under this License.\n\n 8. Limitation of Liability. In no event and under no legal theory,\n whether in tort (including negligence), contract, or otherwise,\n unless required by applicable law (such as deliberate and grossly\n negligent acts) or agreed to in writing, shall any Contributor be\n liable to You for damages, including any direct, indirect, special,\n incidental, or consequential damages of any character arising as a\n result of this License or out of the use or inability to use the\n Work (including but not limited to damages for loss of goodwill,\n work stoppage, computer failure or malfunction, or any and all\n other commercial damages or losses), even if such Contributor\n has been advised of the possibility of such damages.\n\n 9. Accepting Warranty or Additional Liability. While redistributing\n the Work or Derivative Works thereof, You may choose to offer,\n and charge a fee for, acceptance of support, warranty, indemnity,\n or other liability obligations and/or rights consistent with this\n License. However, in accepting such obligations, You may act only\n on Your own behalf and on Your sole responsibility, not on behalf\n of any other Contributor, and only if You agree to indemnify,\n defend, and hold each Contributor harmless for any liability\n incurred by, or claims asserted against, such Contributor by reason\n of your accepting any such warranty or additional liability.\n\n END OF TERMS AND CONDITIONS\n\n APPENDIX: How to apply the Apache License to your work.\n\n To apply the Apache License to your work, attach the following\n boilerplate notice, with the fields enclosed by brackets \"[]\"\n replaced with your own identifying information. (Don't include\n the brackets!) The text should be enclosed in the appropriate\n comment syntax for the file format. We also recommend that a\n file or class name and description of purpose be included on the\n same \"printed page\" as the copyright notice for easier\n identification within third-party archives.\n\n Copyright [2020] to [2021] Atlassian Pty Ltd\n\n Licensed under the Apache License, Version 2.0 (the \"License\");\n you may not use this file except in compliance with the License.\n You may obtain a copy of the License at\n\n http://www.apache.org/licenses/LICENSE-2.0\n\n Unless required by applicable law or agreed to in writing, software\n distributed under the License is distributed on an \"AS IS\" BASIS,\n WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.\n See the License for the specific language governing permissions and\n limitations under the License." }, { "path": "Makefile", "content": ".PHONY: help doc-docker doc-build doc-serve\n\nhelp:\n\t @echo \"Atlassian DC helm charts\"\n\t @echo \"\"\n\t @echo \"Commands:\"\n\t @echo \"docs - starts live server with documentation\"\n\n.DEFAULT_GOAL := help\n\ndoc-docker:\n\t@docker build -t squidfunk/mkdocs-material docs/build/\n\ndoc-build:\n\t@docker run --rm -it -v ${PWD}/docs:/docs squidfunk/mkdocs-material build\n\ndoc-serve:\n\t@docker run --rm -it -p 8000:8000 -v ${PWD}/docs:/docs squidfunk/mkdocs-material\n\ndocs: doc-docker doc-serve" }, { "path": "README.md", "content": "# Atlassian Data Center Helm Charts\n\n[![Artifact Hub](https://img.shields.io/endpoint?url=https://artifacthub.io/badge/repository/atlassian-data-center)](https://artifacthub.io/packages/search?repo=atlassian-data-center)\n[![Atlassian license](https://img.shields.io/badge/license-Apache%202.0-blue.svg?style=flat-square)](LICENSE) \n[![PRs Welcome](https://img.shields.io/badge/PRs-welcome-brightgreen.svg?style=flat-square)](CONTRIBUTING.md) \n[![Maven unit tests](https://github.com/atlassian/data-center-helm-charts/actions/workflows/maven.yml/badge.svg)](https://github.com/atlassian/data-center-helm-charts/actions/workflows/maven.yml)\n\nThis project contains [Helm charts](https://helm.sh/) for installing Atlassian's [Jira Data Center](https://www.atlassian.com/enterprise/data-center/jira), [Confluence Data Center](https://www.atlassian.com/enterprise/data-center/confluence), [Bitbucket Data Center](https://www.atlassian.com/enterprise/data-center/bitbucket) and [Bamboo Data Center](https://www.atlassian.com/software/bamboo) on Kubernetes. \n\nUse the charts to install and operate Data Center products within a Kubernetes cluster of your choice. It can be a managed environment, such as [Amazon EKS](https://aws.amazon.com/eks/), [Azure Kubernetes Service](https://azure.microsoft.com/en-au/services/kubernetes-service/), [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine), or a custom on-premise system.\n\n## Get started\n\n**Get started right now using our [documentation](https://atlassian.github.io/data-center-helm-charts/).**\n\nWe provide extensive documentation to support our Helm charts. This includes prerequisites, set up, installation, examples, and more.\n\n\n## Support disclaimer\n\nWe **don’t officially support** the functionality described in the [examples](https://atlassian.github.io/data-center-helm-charts/examples/EXAMPLES/) or the documented [platforms](https://atlassian.github.io/data-center-helm-charts/platforms/PLATFORMS/). You should use them for reference only. \n\n\n## Feedback\n\nIf you find any issue, [raise a ticket](https://support.atlassian.com/contact/). If you have general feedback or question regarding the charts, use [Atlassian Community Kubernetes space](https://community.atlassian.com/t5/Atlassian-Data-Center-on/gh-p/DC_Kubernetes).\n \n\n## Contributions\n\nContributions are welcome. [Find out how to contribute](CONTRIBUTING.md). \n\n\n## License\n\nCopyright (c) [2020] to [2021] Atlassian and others.\nApache 2.0 licensed, see [license file](LICENSE).\n" }, { "path": "cr.yaml", "content": "pages-branch: gh-pages\nindex-path: docs/docs/index.yaml\n" }, { "path": "docs/build/Dockerfile", "content": "FROM squidfunk/mkdocs-material\nRUN pip install mkdocs-awesome-pages-plugin\n" }, { "path": "docs/docs/.pages", "content": "nav:\n - Home: README.md\n - User guide: userguide\n - Examples: examples\n - Troubleshooting: troubleshooting\n - Platforms: platforms\n - Containers: containers\n" }, { "path": "docs/docs/README.md", "content": "# Atlassian Data Center Helm Charts\n\n[![Artifact Hub](https://img.shields.io/endpoint?url=https://artifacthub.io/badge/repository/atlassian-data-center)](https://artifacthub.io/packages/search?repo=atlassian-data-center)\n[![Atlassian license](https://img.shields.io/badge/license-Apache%202.0-blue.svg?style=flat-square)](https://github.com/atlassian/data-center-helm-charts/blob/main/LICENSE) \n[![PRs Welcome](https://img.shields.io/badge/PRs-welcome-brightgreen.svg?style=flat-square)](https://github.com/atlassian/data-center-helm-charts/blob/main/CONTRIBUTING.md) \n[![Maven unit tests](https://github.com/atlassian/data-center-helm-charts/actions/workflows/maven.yml/badge.svg)](https://github.com/atlassian/data-center-helm-charts/actions/workflows/maven.yml)\n\nThis project contains [Helm charts](https://helm.sh/){.external} for installing Atlassian's [Jira Data Center](https://www.atlassian.com/enterprise/data-center/jira){.external}, [Confluence Data Center](https://www.atlassian.com/enterprise/data-center/confluence){.external}, [Bitbucket Data Center](https://www.atlassian.com/enterprise/data-center/bitbucket){.external}, [Bamboo Data Center](https://www.atlassian.com/software/bamboo){.external} and [Crowd Data Center](https://www.atlassian.com/software/crowd){.external} on Kubernetes.\n\nUse the charts to install and operate Data Center products within a Kubernetes cluster of your choice. It can be a managed environment, such as [Amazon EKS](https://aws.amazon.com/eks/){.external}, [Azure Kubernetes Service](https://azure.microsoft.com/en-au/services/kubernetes-service/){.external}, [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine){.external}, or a custom on-premise system.\n\n## Support disclaimer\n\n!!! warning \"Support Disclaimer\"\n Helm is a Kubernetes package manager that orchestrates the provisioning of applications onto existing Kubernetes infrastructure. The requirements for this infrastructure are described in [Prerequisites](userguide/PREREQUISITES.md). The Kubernetes cluster remains your responsibility; we do not provide direct support for Kubernetes or the underlying hardware it runs on.\n\n If you have followed our documentation on how to configure the Helm charts, and you're using correctly created components, we will then provide support if you encounter an error with installation after running the `helm install` command. \n\n We **don’t officially support** the functionality described in the [examples](examples/EXAMPLES.md) or the documented [platforms](platforms/PLATFORMS.md). You should use them for reference only.\n \n Read more about [what we support and what we don’t](troubleshooting/SUPPORT_BOUNDARIES.md). \n \n **Certain product limitations listed below:**\n\n * **Jira** currently has [limitations with scaling](troubleshooting/LIMITATIONS.md#jira-and-horizontal-scaling).\n * **Bamboo** has a number of limitations, [particularly with deployment and clustering](troubleshooting/LIMITATIONS.md#deployment).\n \n Read more about these [product and platform limitations](troubleshooting/LIMITATIONS.md).\n\n## Architecture\n\nThe diagram below provides a high level overview of what a typical deployment might look like when using the Atlassian Data Center Helm charts:\n\n![architecture](assets/images/KubernetesOverview.png \"Request routing via Ingress\")\n\n## Installing the Helm charts\n\n* [Prerequisites and setup](userguide/PREREQUISITES.md) - everything you need to do before installing the Helm charts\n* [Verification](userguide/VERIFICATION.md) - verify the integrity of the Helm charts\n* [Installation](userguide/INSTALLATION.md) - the steps to install the Helm charts\n* [Migration](userguide/MIGRATION.md) - what you have to do if you're migrating an existing deployment to Kubernetes\n\n## Additional content\n\n* [Operation](userguide/OPERATION.md) - how to upgrade applications, scale your cluster, and update resources\n* [Configuration](userguide/CONFIGURATION.md) - a deep dive into the configuration parameters\n* [Platforms support](platforms/PLATFORMS.md) - how to allow support for different platforms\n* [Examples](examples/EXAMPLES.md) - various configuration examples\n* [Troubleshooting](troubleshooting/TROUBLESHOOTING.md) - how to debug issues with installation\n\n\n## Product versions\nThese Helm charts support all product versions that have not reached End of Life (EOL). Please refer to the [Atlassian End of Support Policy](https://confluence.atlassian.com/support/atlassian-end-of-support-policy-201851003.html){.external} to verify that your product version is currently supported.\n\nThe Helm charts are product-version agnostic and do not assume or require a specific product version. This means you do not need to wait for a new Helm chart release before upgrading your product to a newer version — the two can be updated independently.\n\nNew Helm chart releases typically introduce improvements and new features to make the charts more flexible and easier to configure. Occasionally, a new chart release adds support for new product features, but these are almost always opt-in and will not affect existing deployments unless explicitly configured. \n\n## Feedback\n\nIf you find any issues, [raise a ticket](https://support.atlassian.com/contact/){.external}. If you have general feedback or questions regarding the charts, use [Atlassian Community Kubernetes space](https://community.atlassian.com/t5/Atlassian-Data-Center-on/gh-p/DC_Kubernetes){.external}.\n \n\n## Contributions\n\nContributions are welcome. [Find out how to contribute](https://github.com/atlassian/data-center-helm-charts/blob/main/CONTRIBUTING.md){.external}. \n\n\n## License\n\nApache 2.0 licensed, see [license file](https://github.com/atlassian/data-center-helm-charts/blob/main/LICENSE){.external}.\n" }, { "path": "docs/docs/artifacthub-repo.yml", "content": "# Artifact Hub repository metadata file\n#\n# Some settings like the verified publisher flag or the ignored packages won't\n# be applied until the next time the repository is processed. Please keep in\n# mind that the repository won't be processed if it has not changed since the\n# last time it was processed. Depending on the repository kind, this is checked\n# in a different way. For Helm http based repositories, we consider it has\n# changed if the `index.yaml` file changes. For git based repositories, it does\n# when the hash of the last commit in the branch you set up changes. This does\n# NOT apply to ownership claim operations, which are processed immediately.\n#\n# https://artifacthub.io/docs/topics/repositories/#helm-charts-repositories\nrepositoryID: 46e7e8b1-a8bb-47bf-837f-63d7ff61a463\nowners:\n - name: abrokes-atlassian\n email: abrokes@atlassian.com\n" }, { "path": "docs/docs/assets/images/KubernetesOverview.xml", "content": "\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n\n" }, { "path": "docs/docs/assets/images/ingress.xml", "content": "\n7V1bc+o4Ev41VM0+QFmSL/B4IMnsmc2cPTWZqrMzLyljBHhiLNY2CZlfP5ItGcsWxATfQswLWLLbdvfXF0mtZoBmm/3Pgb1d/0oW2BtAbbEfoJsBhMDSJvSLtbwmLUMEx0nLKnAX/KxDw4P7N+aNGm/duQscSidGhHiRu5UbHeL72ImkNjsIyIt82pJ48l239goXGh4c2yu2/nAX0TppHRvaof3f2F2txZ2BxnvmtvO0CsjO5/cbQLSMP0n3xha0+Pnh2l6Ql0wTuh2gWUBIlPza7GfYY8wVbEuuuzvSmz53gP2ozAW7W2en//b09Pv909y5Nf9cfXv+MbT0hMyz7e2weI/4aaNXwSH2ktsBmhZvyJ/hGQcR3qukZc8FkcMbUyhhssFR8ErP41cZVnIZBxGAOkoaXg4iAbrFObnOyMNEvNHmOFilxA+8oD84O85hjfE2a2LxY0YFUAa9rN0IP2xth/W+UH2hbeto4/HuJfEjjn9g0OMwCsgTnhGPBDE1pGmmOZulPQKOkF3rep440yc+pTFdBfbCpaLIEOD4Q9OFHa7TxyrK7TQU8tI8KjVTqILQfVCU2thUCg1dLrTp8vXrt0f0i+6g5Y/ggTh/PnwZWqggI7yg+s4PSRCtyYr4tnd7aJ0epKjRo8M594RsOQ//wlH0yoVn7yIiSxbv3eh/7PLRZGLw4z/iYxPxw5s9Jx8fvGYOvuPApS+PA96Wh8mZ4gvJLnDwCRYhfiLjSykp67okZaiPoDk5fMbwuCw50e/Epc+eUgRwAiSSBqA0LZlMZAcrHPErc6hIH/L92i2scka7zZESO/f2nPo8Sd625658+tuhImFymzKdcalP+cI7Nu5ikUALh+7f3Aoy4W7Z+8RvaEwHxo3KKlD74fqre7xk0h4CtQafBP8F9jjAnh25z7JvLC/ZYQ4LZLkM8aXyU7+r0Sv6G4oOQOcUHWh5mo0qPRgrXLrpRVwYEpzM/++I6BiGsZi+0BOAsd0fOumvFftmpiOhQ58rIZV0dNGioDMsioiB2rMoSAZQU/bFNMsHxhcq8uXhc0HPdF0fWYoQGimCMWBVEEGreahStxwPMzqQBq2aiKVDOZbOBsE02oVjy7iFqkA6jYNl5ZhqI02jiJ7F5pp+MX2Bs7gDxM0w1zpRtsYk8mdOjhC24qtpv4IIyLWxobN0bqzPdOC4ZVzY7FdsDD562s1x4FNHEo5cChT2msHX+MfNlixK4fE05EsPAARyMhBThvu1AWzSA+xTAIybtXHLeLOKg4Yeb1eBt64ADPQAu06ANYAoZZBpljBZSRzbdNBqGrnQXiwcZFgFdQWvkFEXs5BVe9CfyuNy/sm+MY3ts/E+UMX7sDb29fF+w9bLedy8H4op2kuHY6AIsYkCYeO6AKaXNmYd0E+gywqql2NeqrPVc68PLhpWT9dfvR+J+jEkngwumtVH+IH1sQMKid5mX6+Q3VFIeASKHVLIM9I52lPI4w5RGe+nLKyeXSVSPHoF7I4Cls9QaUsBjWaShi5IDTqedVS9FMQaHpAXloemanEKCt7Jum+k51YvLNUa35nLwVC1HDyjJwXE83BQdlmYcjKSBS/LiQtWIevyK8cqpMkZEfXrJe+doJEhQQIolpKUvqA2xVVN/VSBhf/O/6I+8afwXz0USkKhaBqaRUIFSSI9EqpAAjRaNgpWEQp6MUmwG2KSUn7bk5lYkm9LZHr9eTvVjYA6MAVRYsWjHwF1ZwT0rgXHZkdAoACgRhNzGXzaScwVdiGbmHtynSzJdj0lbm5b38zgLZ1keZloi7bho+VcUwkGrwk1Qxz+IW7EDg6k4qPX7FF3cVI207shnLS8CacCE3AMJ9rHxonVLZzoV2tPPjhOULdwokrzrWLbxld/FeAwfP94vMptGwypIZf+0TFkxSOWo+O6sVEYmKjS1mobxpmthhpAMgvGaatwsADc76Q2gBuUhsyAal/YyTWKrBm4bANZM2bAbDWs6DFx3u7hhjDRagjRYyLBRLfshFVMqzE6sbW7rLeuLMV6qI10E8mLr5zSe7dlVrrzUv36/c7uN0s4VK5wOSkf9pXK4EGi3E9DG7YVu3C7UaWhrCpfvn/6oMoQiPWoS8UqX1DfJuqJ1YYqX6h9ZcslpCVERDrbpdUSIJIJUmUrWxWlKGLtbVqJmalNd+satIMu1VrgtRV+j6GpDfLFFjItv/FRs1EKoSfVqcVqDKYqlqjfkACtRGKrHW6TAnFLd8/sR1bmiumWPArcTVwpriAc3n7jblb02T13zt4gdGxMv2++PYzC59Ugn5dnnm92ys/NwHwiu3monpStvFXTqt8RAakSH6tQd8pihluyi9jK6bXP1L0DDTmvAVFx6i71BlXP3R2ZNtIKAund/lGbqsO8qx6PDCND0nhfCIAK4cRpujWHAwIUGQMBOxrKn0Z1C963/kF3ia2BBfe6zYx66S3cbYgzA+GT4ktroUqZa5loKQmoUMYtq9yw7TBuPi7cgD4ZYay7eyHBUxhRLhP/0fFYEvxRB12/iU7zGCejiaEdPiUtNADWSEwGVT5LBktEVNTpeq5PXZsovSsmN7IpXgjesdsWNh1wR6j0jpLIhS7Hev+delYmPNo3J1FENgpljxg4iqA64QviY/5e7JZFLDNNw8HtM06sBRgUk7rsl1Af+ThiEHv0iL14nNue7TvxzXOJb5pm3d3d1en39bzftzRVFCimDLK4ssY1YQqpzEgVQeC3hOu0/37ax4BFLEB5mk4VA6qSAOtbvi1RCQL7iy+sfjcTiGeHoes0G89leGMoeCPaLhwxG7m9TywKs8pNxBRo5afyVbTqnpAtzuqgTkRxUtwwhGdM0QqoVjFFq42RXNRm2KXllpOL/H0GeFMZ4OGz06RzAFq+2ra6Bm8DCeNKAMIK9lspg4YHHDy7FJp9vFCABNBkSCBNPYuRDSSbnEJSBpK9UbpiowSNQyzTliVCsLdEbVsi1dClWdNTYl6kNz3XZHp09fpZs6anruWz3vSUNj26DpUzaI1anwrKUDAcxADIQeE7WWSKD8yDi4j1gCoCCkGzgJ66dk0o0aMsXdH7rg6Uj64MYmYuXDqy/NxWAfM+ePpkADz2j05tAbCv6HflACz7l2Kt/SdND8DPBcCuuWBTNXfaDyE+2BBCgAu0PKQQG7F7e3at9qw4pADdcqh9lfRPhkAEgWoirlnU9SPZK0ddPo7rBOr64esnQ13nvG2/AHE9owcdKv8GutFKTlZFgCoA4D+pUtNTHG8XRpeU2+8eKMDZ4qeMksQPoNhVkt1pUlE5ZnoYECaQtO9nZmt/JQuW9nv7Dw==" }, { "path": "docs/docs/assets/stylesheets/extra.css", "content": ":root > * {\n\n --md-primary-fg-color: #0052CC;\n --md-primary-fg-color--light: #FFFFFF;\n --md-primary-fg-color--dark: #172B4D;\n}\n\n[data-md-color-scheme=\"slate\"] {\n --md-primary-fg-color: #172B4D;\n --md-primary-fg-color--light: #ECB7B7;\n --md-primary-fg-color--dark: #091E42;\n\n --md-typeset-a-color: #4C9AFF\n}\n\na[target=\"_blank\"]::after, a.external::after {\n content: url(\"../../icons/link_external.svg\");\n margin: 0 2px 0 2px;\n vertical-align: super;\n}\n\n.atl-bright-color {\n color: #0065FF !important;\n}\n" }, { "path": "docs/docs/containers/.pages", "content": "nav:\n - Jira: JIRA.md\n - Confluence: CONFLUENCE.md\n - Bitbucket: BITBUCKET.md\n - Bitbucket Mesh: BITBUCKET-MESH.md\n - Bamboo Agent: BAMBOO-AGENT.md\n - Bamboo: BAMBOO.md\n - Crowd: CROWD.md\n - ...\n" }, { "path": "docs/docs/containers/BAMBOO-AGENT.md", "content": "# ![Atlassian Bamboo](https://wac-cdn.atlassian.com/dam/jcr:560a991e-c0e3-4014-bd7d-2e65d4e4c84a/bamboo-icon-gradient-blue.svg?cdnVersion=814){: style=\"height:35px;width:35px\"} Bamboo Agent\n\n## Overview\n\nA Bamboo Agent is a service that can run job builds. Each agent has a defined set of capabilities and can run builds\nonly for jobs whose requirements match the agent's capabilities. \n\n\nIf you are looking for **Bamboo Docker Image** it can be found [here](https://hub.docker.com/r/atlassian/bamboo/).\nTo learn more about Bamboo, see: \n\nThis Docker container makes it easy to get a Bamboo Remote Agent up and running. It is intended to be used as a base to \nbuild from, and as such contains limited built-in capabilities:\n\n* JDK 11, JDK 17 (from v9.4.0), JDK 21 (from v10.1.0)\n* Git & Git LFS\n* Maven 3\n* Python 3\n\nUsing this image as a base, you can create a custom remote agent image with your\ndesired build tools installed. Note that Bamboo Agent Docker Image does not\ninclude a Bamboo server.\n\n**Use docker version >= 20.10.9.**\n\n## Quick Start\n\nFor the `BAMBOO_AGENT_HOME` directory that is used to store the repository data (amongst other things) we recommend mounting a host directory as a [data volume](https://docs.docker.com/engine/tutorials/dockervolumes/#/data-volumes), or via a named volume.\n\nTo get started you can use a data volume, or named volumes. In this example we'll use named volumes.\n\nRun an Agent:\n```shell\ndocker volume create --name bambooAgentVolume\ndocker run -e BAMBOO_SERVER=http://bamboo.mycompany.com/agentServer/ -v bambooAgentVolume:/var/atlassian/application-data/bamboo-agent --name=\"bambooAgent\" --hostname=\"bambooAgent\" -d atlassian/bamboo-agent-base\n```\n!!! success \"The Bamboo remote agent is now available to be approved in your Bamboo administration.\"\n\n### Verbose container entrypoint logging\n\nDuring the startup process of the container, various operations and checks are performed to ensure that the application\nis configured correctly and ready to run. To help in troubleshooting and to provide transparency into this process, you\ncan enable verbose logging. The `VERBOSE_LOGS` environment variable enables detailed debug messages to the container's\nlog, offering insights into the actions performed by the entrypoint script.\n\n* `VERBOSE_LOGS` (default: false)\n\n Set to `true` to enable detailed debug messages during the container initialization.\n\n## Configuration\n\n* `BAMBOO_SERVER` (required)\n\n The URL of the Bamboo Server the remote agent should connect to, e.g. `http://bamboo.mycompany.com/agentServer/`\n\n* `SECURITY_TOKEN` (default: NONE)\n\n If security token verification is enabled, this value specifies the token required to authenticate to the Bamboo server\n\n* `WRAPPER_JAVA_INITMEMORY` (default: 256)\n\n The minimum heap size of the JVM. This value is in MB and should be specified as an integer\n\n* `WRAPPER_JAVA_MAXMEMORY` (default: 512)\n\n The maximum heap size of the JVM. This value is in MB and should be specified as an integer\n\n* `IGNORE_SERVER_CERT_NAME` (default: false)\n\n Ignore SSL certificate hostname if it's issued to a different host than the one under your Bamboo Base URL hostname\n\n* `ALLOW_EMPTY_ARTIFACTS` (default: false)\n\n Allow empty directories to be published as artifacts\n\n* `BAMBOO_AGENT_PERMISSIVE_READINESS` (default: unset/false)\n\n If set to 'true', the readiness probe will be more permissive and not expect\n the agent to be fully configured, only that the startup wrapper is\n running. This is primarily intended for use when deploying agents into\n environments where the server may not yet be configured.\n\n* `BAMBOO_AGENT_CLASSPATH_DIR` (default: NONE)\n\n If set, agent startup process will copy agent classpath from designated location instead of downloading it from the server.\n This can speed up the process and reduce the load on the Bamboo server.\n\n### Dedicated agent specific configuration\n\n* `AGENT_EPHEMERAL_FOR_KEY` (default: NONE)\n\n The value specifies the purpose for spawning the agent. It needs to be a valid ResultKey.\n\n* `KUBE_NUM_EXTRA_CONTAINERS` (default: 0) \n\n The number of extra containers that run in parallel with the Bamboo Agent. We make sure these extra containers are run before the Agent kick in.\n\n* `EXTRA_CONTAINERS_REGISTRATION_DIRECTORY` (default: /pbc/kube)\n\n The directory where extra containers should register their readiness by creating any file. The image waits for having `KUBE_NUM_EXTRA_CONTAINERS` number of files inside this directory (if the one exists) before processing further and running the actual agent.\n\n### Ephemeral agent specific configuration\n\n* `BAMBOO_EPHEMERAL_AGENT_DATA` (default: NONE)\n\n The Bamboo Ephemeral Agents specific configuration. It was designed to pass multiple key-value properties separated by the `#`. Example: `BAMBOO_SERVER=http://localhost#SECURITY_TOKEN=123456789#bamboo.agent.ephemeral.for.key=PROJ-PLAN-JOB1-1`\n\n### Additional agent wrapper properties\n\n* `BAMBOO_WRAPPER_JAVA_ADDITIONAL_PROPERTIES` (default: NONE)\n\n Adds `wrapper.java.additional.X` entries to the Agent's `conf/wrapper.conf`. It was designed to pass multiple key-value properties separated by the `#`. Example: `log4j2.configurationFile=/path/to/log4j2.properties#javax.net.ssl.keyStore=/var/atlassian/application-data/bamboo-agent/ssl/bamboo.secure.client.ks`\n\n## Extending base image\n\nThis Docker image contains only minimal setup to run a Bamboo agent which might not be sufficient to run your builds. If you need additional capabilities you can extend the image to suit your needs.\n\nExample of extending the agent base image by Maven and Git:\n```Dockerfile\nFROM atlassian/bamboo-agent-base:9.6.8\nUSER root\nRUN apt-get update && \\\n apt-get install maven -y && \\\n apt-get install git -y\n\nUSER ${BAMBOO_USER}\nRUN /bamboo-update-capability.sh \"system.builder.mvn3.Maven 3.3\" /usr/share/maven\nRUN /bamboo-update-capability.sh \"system.git.executable\" /usr/bin/git\n```\n\n## Building your own image\n\n* Clone the Atlassian repository at \n* Modify or replace the [Jinja](https://jinja.palletsprojects.com/) templates\n under `config`; _NOTE_: The files must have the `.j2` extensions. However you\n don't have to use template variables if you don't wish.\n* Build the new image with e.g: `docker build --tag my-bamboo-image --platform linux/amd64,linux/arm64 --build-arg BAMBOO_VERSION=X.Y.Z .`\n* Optionally push to a registry, and deploy.\n\n## Issue tracker\n\n* You can view know issues [here](https://jira.atlassian.com/projects/BAM/issues/filter=allissues).\n* Please contact our support if you encounter any problems with this Dockerfile.\n\n## Supported JDK versions and base images\n\nBamboo Docker images are based on JDK 11, JDK 17 (from Bamboo 9.4), and JDK 21 (from Bamboo 10.1) and generated from the\n[official Eclipse Temurin OpenJDK Docker images](https://hub.docker.com/_/eclipse-temurin) and\n[Red Hat Universal Base Images](https://catalog.redhat.com/software/containers/ubi9/openjdk-17/61ee7c26ed74b2ffb22b07f6?architecture=amd64).\nStarting in Bamboo 9.4, UBI tags are available in 2 formats: `-ubi9`, `-ubi9-jdk17`, or `-ubi9-jdk21>`\n\nThe Docker images follow the [Atlassian Support end-of-life\npolicy](https://confluence.atlassian.com/support/atlassian-support-end-of-life-policy-201851003.html);\nimages for unsupported versions of the products remain available but will no longer\nreceive updates or fixes.\n\nHowever, Bamboo is an exception to this. Due to the need to support JDK 11 and\nKubernetes, we currently only generate new images for Bamboo 9.1 and up. Legacy\nbuilds for JDK 8 are still available in Docker Hub, and building custom images\nis available (see above).\n\nHistorically, we have also generated other versions of the images, including\nJDK 8, Alpine, and 'slim' versions of the JDK. These legacy images still exist in\nDocker Hub, however they should be considered deprecated, and do not receive\nupdates or fixes.\n\nIf for some reason you need a different version, see \"Building your own image\".\n\n## Migration to UBI\n\nIf you have been mounting any files to `${JAVA_HOME}` directory in `eclipse-temurin` based container, `JAVA_HOME` in UBI container is set to `/usr/lib/jvm/java-17` (JDK17) and `/usr/lib/jvm/java-21` (JDK21).\n\nAlso, if you have been mounting and running any custom scripts in the container, UBI-based images may lack some tools and utilities that are available out of the box in eclipse-temurin tags. If that's the case, see [Building your own image](#building-your-own-image).\n\n## Supported architectures\n\nCurrently, the Atlassian Docker images are built for the `linux/amd64` and `linux/arm64` target\nplatforms; we do not have other architectures on our roadmap at this\npoint. However, the Dockerfiles and support tooling have now had all\narchitecture-specific components removed, so if necessary it is possible to\nbuild images for any platform supported by Docker.\n\n### Building on the target architecture\n\nThe simplest method of getting a platform image is to build it on a target\nmachine; and specify either `linux/amd64` or `linux/arm64`. See [Building your own image](#building-your-own-image) above.\n\nNote: This method is known to work on Mac M1 and AWS ARM64 machines, but has not\nbeen extensively tested.\n\n## Support\n\nFor product support, go to \n\nYou can also visit the [Atlassian Data Center](https://community.atlassian.com/t5/Atlassian-Data-Center-on/gh-p/DC_Kubernetes)\nforum for discussion on running Atlassian Data Center products in containers.\n" }, { "path": "docs/docs/containers/BAMBOO.md", "content": "# ![Atlassian Bamboo](https://wac-cdn.atlassian.com/dam/jcr:560a991e-c0e3-4014-bd7d-2e65d4e4c84a/bamboo-icon-gradient-blue.svg?cdnVersion=814){: style=\"height:35px;width:35px\"} Bamboo\n\n!!! warning \"Server image deprecation\"\n This Docker image has been published as both `atlassian/bamboo` and `atlassian/bamboo-server` up until February 15, 2024.\n Both names refer to the same image. However, post-February 15, 2024, the `atlassian/bamboo-server` version ceased \n receiving updates, including both existing and new tags. If you have been using `atlassian/bamboo-server`, \n switch to the `atlassian/bamboo` image to ensure access to the latest updates and new tags.\n\n\n## Overview\n\nBamboo is a continuous integration and deployment tool that ties automated builds, tests and releases together in a single workflow.\n\nLearn more about Bamboo: \n\nThis Docker container makes it easy to get an instance of Bamboo up and running.\n\n**Use docker version >= 20.10.10**\n\n## Quick Start\n\nFor the `BAMBOO_HOME` directory that is used to store the repository data\n(amongst other things) we recommend mounting a host directory as a [data\nvolume](https://docs.docker.com/engine/tutorials/dockervolumes/#/data-volumes),\nor via a named volume.\n\nAdditionally, if running Bamboo in Data Center mode it is required that a\nshared filesystem is mounted.\n\nTo get started you can use a data volume, or named volumes. In this example\nwe'll use named volumes.\n```shell\ndocker volume create --name bambooVolume\ndocker run -v bambooVolume:/var/atlassian/application-data/bamboo --name=\"bamboo\" -d -p 8085:8085 -p 54663:54663 atlassian/bamboo\n```\n!!! success \"Bamboo is now available on .\"\n\nPlease ensure your container has the necessary resources allocated to it. We\nrecommend 2GiB of memory allocated to accommodate the application server. See\n[System Requirements](https://confluence.atlassian.com/display/BAMBOO/Bamboo+Best+Practice+-+System+Requirements)\nfor further information.\n\n!!! tip \"If you are using `docker-machine` on Mac OS X, please use `open http://$(docker-machine ip default):8085` instead.\"\n\n\n## Common settings\n\n### Verbose container entrypoint logging\n\nDuring the startup process of the container, various operations and checks are performed to ensure that the application\nis configured correctly and ready to run. To help in troubleshooting and to provide transparency into this process, you\ncan enable verbose logging. The `VERBOSE_LOGS` environment variable enables detailed debug messages to the container's\nlog, offering insights into the actions performed by the entrypoint script.\n\n* `VERBOSE_LOGS` (default: false)\n\n Set to `true` to enable detailed debug messages during the container initialization.\n\n### Memory / Heap Size\n\nIf you need to override Bamboo's default memory allocation, you can control the minimum heap (Xms) and maximum heap (Xmx) via the below environment variables.\n\n* `JVM_MINIMUM_MEMORY` (default: 512m)\n\n The minimum heap size of the JVM\n\n* `JVM_MAXIMUM_MEMORY` (default: 1024m)\n\n The maximum heap size of the JVM\n\n### Tomcat and Reverse Proxy Settings\n\nIf Bamboo is run behind a reverse proxy server as [described\nhere](https://confluence.atlassian.com/kb/integrating-apache-http-server-reverse-proxy-with-bamboo-753894403.html),\nthen you need to specify extra options to make Bamboo aware of the setup. They\ncan be controlled via the below environment variables.\n\n* `ATL_PROXY_NAME` (default: NONE)\n\n The reverse proxy's fully qualified hostname. `CATALINA_CONNECTOR_PROXYNAME`\n is also supported for backwards compatibility.\n\n* `ATL_PROXY_PORT` (default: NONE)\n\n The reverse proxy's port number via which Bamboo is\n accessed. `CATALINA_CONNECTOR_PROXYPORT` is also supported for backwards\n compatibility.\n\n* `ATL_TOMCAT_PORT` (default: 8085)\n\n The port for Tomcat/Bamboo to listen on. Depending on your container\n deployment method this port may need to be\n [exposed and published][docker-expose].\n\n* `ATL_TOMCAT_PROTOCOL` (default: HTTP/1.1)\n\n The protocol to be used by Tomcat. Bamboo provides additional customized protocols that will support encryption\n along with `ATL_TOMCAT_BAMBOO_ENCRYPTION_KEY`. For more information, see [Encrypting passwords in server][encrypting-passwords-in-server].\n\n* `ATL_TOMCAT_SCHEME` (default: http)\n\n The protocol via which the application is accessed. `CATALINA_CONNECTOR_SCHEME` is also\n supported for backwards compatibility.\n\n* `ATL_TOMCAT_SECURE` (default: false)\n\n Set 'true' if `ATL_TOMCAT_SCHEME` is 'https'. `CATALINA_CONNECTOR_SECURE` is\n also supported for backwards compatibility.\n\n* `ATL_TOMCAT_CONTEXTPATH` (default: NONE)\n\n The context path the application is served over. `CATALINA_CONTEXT_PATH` is\n also supported for backwards compatibility.\n\nThe following Tomcat/Catalina options are also supported. For more information,\nsee .\n\n* `ATL_TOMCAT_ACCEPTCOUNT` (default: 100)\n* `ATL_TOMCAT_CONNECTIONTIMEOUT` (default: 20000)\n* `ATL_TOMCAT_ENABLELOOKUPS` (default: false)\n* `ATL_TOMCAT_MAXHTTPHEADERSIZE` (default: 8192)\n* `ATL_TOMCAT_MAXTHREADS` (default: 150)\n* `ATL_TOMCAT_MGMT_PORT` (default: 8007)\n* `ATL_TOMCAT_MINSPARETHREADS` (default: 25)\n* `ATL_TOMCAT_URIENCODING` (default: UTF-8)\n* `ATL_TOMCAT_STUCKTHREADDETECTIONVALVE_THRESHOLD` (default: 60)\n\nThe standard HTTP connectors (NIO, NIO2 and APR/native) settings\n\n* `ATL_TOMCAT_ADDRESS`\n\n For servers with more than one IP address, this attribute specifies which \n address will be used for listening on the specified port.\n\n* `ATL_TOMCAT_SECRET` (default: null)\n\n Only requests from workers with this secret keyword will be accepted. The\n default value is null. This attribute must be specified with a non-null, \n non-zero length value unless secretRequired is explicitly configured to be false. \n If this attribute is configured with a non-null, non-zero length value then the workers\n must provide a matching value else the request will be rejected irrespective of the\n setting of secretRequired.\n\n* `ATL_TOMCAT_SECRET_REQUIRED` (default: false)\n\n If this attribute is true, the AJP Connector will only start if the secret \n attribute is configured with a non-null, non-zero length value. This attribute only \n controls whether the secret attribute is required to be specified for the AJP Connector\n to start. It does not control whether workers are required to provide the secret. The\n default value is true. This attribute should only be set to false when the Connector \n is used on a trusted network.\n\n* `ATL_TOMCAT_BAMBOO_ENCRYPTION_KEY`\n \n File which contains encryption key used for Bamboo-specific connectors.\n\n* `ATL_TOMCAT_SSL_ENABLED`\n\n Set this attribute to `true` to enable SSL traffic on a connector.\n\n* `ATL_TOMCAT_SSL_PROTOCOL`\n\n JSSE only. The SSL protocol(s) to use (a single value may enable multiple protocols\n - see the JVM documentation for details).\n \n* `ATL_TOMCAT_SSL_CERTIFICATE_FILE`\n\n Name of the file that contains the server certificate. The format is PEM-encoded. \n Relative paths will be resolved against $CATALINA_BASE.\n\n* `ATL_TOMCAT_SSL_CERTIFICATE_KEY_FILE`\n\n Name of the file that contains the server private key. The format is PEM-encoded. \n The default value is the value of certificateFile and in this case both certificate\n and private key have to be in this file (NOT RECOMMENDED). Relative paths will be \n resolved against $CATALINA_BASE.\n\n* `ATL_TOMCAT_SSL_PASS`\n\n The password used to access the private key associated with the server certificate \n from the specified file.\n\n* `ATL_TOMCAT_KEYSTORE_FILE`\n\n JSSE only. The pathname of the keystore file where you have stored the server certificate\n and key to be loaded. By default, the pathname is the file .keystore in the operating \n system home directory of the user that is running Tomcat.\n\n* `ATL_TOMCAT_KEYSTORE_PASS`\n\n JSSE only. The password to use to access the keystore containing the server's private\n key and certificate. If not specified, a default of _changeit_ will be used.\n\n* `ATL_TOMCAT_KEY_PASS`\n\n The password used to access the private key associated with the server certificate \n from the specified file.\n\n* `ATL_TOMCAT_KEY_ALIAS`\n\n Specify the key alias to be loaded in case the provided keystore contains multiple \n private key aliases.\n\n* `ATL_TOMCAT_CLIENT_AUTH`\n \n Set to required if you want the SSL stack to require a valid certificate chain from\n the client before accepting a connection. Set to optional if you want the SSL stack\n to request a client Certificate, but not fail if one isn't presented. Set to optionalNoCA\n if you want client certificates to be optional and you don't want Tomcat to check them \n against the list of trusted CAs. If the TLS provider doesn't support this option (OpenSSL\n does, JSSE does not) it is treated as if optional was specified. A none value (which is \n the default) will not require a certificate chain unless the client requests a resource \n protected by a security constraint that uses CLIENT-CERT authentication.\n\n* `ATL_TOMCAT_TRUSTSTORE_FILE`\n\n JSSE only. The trust store file to use to validate client certificates. The default is\n the value of the javax.net.ssl.trustStore system property. If neither this attribute nor\n the default system property is set, no trust store will be configured. Relative paths will\n be resolved against $CATALINA_BASE. A URL may also be used for this attribute.\n\n* `ATL_TOMCAT_TRUSTSTORE_PASS`\n\n JSSE only. The password to access the trust store. The default is the value of the \n javax.net.ssl.trustStorePassword system property. If that property is null, no trust\n store password will be configured. If an invalid trust store password is specified, \n a warning will be logged and an attempt will be made to access the trust store without\n a password which will skip validation of the trust store contents.\n\n* `ATL_TOMCAT_COMPRESSION`\n\n Enables HTTP compression. The acceptable values for the parameter are:\n\n* `off` or `0` - disabled compression\n* `on` - enabled compression\n* `force` - forces compression in all cases\n* `numerical integer value`, e.g. `100` - which is equivalent to `on`, but specifies the \n minimum amount of data before the output is compressed. If the content length is not known\n and compression is set to `on` or more aggressive, the output will also be compressed.\n\n If not specified, compression will remain disabled.\n\n* `ATL_TOMCAT_COMPRESSIBLEMIMETYPE`\n\n A comma-separated list of MIME types for which HTTP compression may be used.\n Only applicable if `ATL_TOMCAT_COMPRESSION` is set to `on` or `force`.\n If not specified, this attribute defaults to \n `text/html,text/xml,text/plain,text/css,text/javascript,application/javascript,application/json,application/xml`.\n\n* `ATL_TOMCAT_COMPRESSIONMINSIZE`\n\n The minimum amount of data before the output is compressed. Only applicable if \n `ATL_TOMCAT_COMPRESSION` is set to `on` or `force`. If not specified, this attribute \n defaults to `2048`.\n\n* `ATL_TOMCAT_REQUESTATTRIBUTESENABLED`\n\n Checks for the existence of request attributes (typically set by the RemoteIpValve and similar) \n that should be used to override the values returned by the request for remote address, \n remote host, server port and protocol. This property is usually combined with `ATL_TOMCAT_TRUSTEDPROXIES`\n and `ATL_TOMCAT_INTERNALPROXIES` to show IP address of the remote host instead of the load balancer's.\n If not declared, the default value of `false` will be used.\n\n* `ATL_TOMCAT_TRUSTEDPROXIES`\n\n A list of IP addresses separated by a pipe character e.g. `10.0.9.6|10.0.9.32`. \n Trusted proxies that appear in the `remoteIpHeader` will be trusted and *will appear* \n in the `proxiesHeader` value. By adding a list of Trusted Proxies, Bamboo will remove the \n load balancers' IP addresses from Bamboo's view of the incoming connection. This could be desired\n in a clustered load balancer architecture where the load balancer address changes depending on \n which node proxies the connection, requiring re-approval of Agents. \n If not specified, no trusted proxies will be trusted.\n\n* `ATL_TOMCAT_INTERNALPROXIES`\n\n A list of IP addresses separated by a pipe character e.g. `10.0.9.6|10.0.9.32`. \n Trusted proxies that appear in the `remoteIpHeader` will be trusted and *will not appear* \n in the `proxiesHeader` value. By adding a list of Internal Proxies, Bamboo will remove the \n load balancers' IP addresses from Bamboo's view of the incoming connection. This could be desired\n in a clustered load balancer architecture where the load balancer address changes depending on \n which node proxies the connection, requiring re-approval of Agents.\n If not specified, no internal proxies will be trusted.\n\n### Access Log Settings\n\nYou can set the maximum number of days for access logs to be retained before being deleted. The default value of -1 means never delete old files.\n\n* `ATL_TOMCAT_ACCESS_LOGS_MAXDAYS` (default: -1)\n\n\n### JVM configuration\n\nIf you need to pass additional JVM arguments to Bamboo, such as specifying a\ncustom trust store, you can add them via the below environment variable\n\n* `JVM_SUPPORT_RECOMMENDED_ARGS`\n\n Additional JVM arguments for Bamboo. \n\n??? example\n `docker run -e JVM_SUPPORT_RECOMMENDED_ARGS=-Djavax.net.ssl.trustStore=/var/atlassian/application-data/bamboo/cacerts\n -v bambooVolume:/var/atlassian/application-data/bamboo --name=\"bamboo\" -d -p 8085:8085 -p 54663:54663 atlassian/bamboo`\n\n### Bamboo-specific settings\n\n* `ATL_AUTOLOGIN_COOKIE_AGE` (default: 1209600; two weeks, in seconds)\n\n The maximum time a user can remain logged-in with 'Remember Me'.\n\n* `BAMBOO_HOME`\n\n The Bamboo home directory. This may be on an mounted volume; if so it\n should be writable by the user `bamboo`. See note below about UID\n mappings.\n\n* `ATL_BROKER_URI` (default: nio://0.0.0.0:54663)\n\n The ActiveMQ Broker URI to listen on for in-bound remote agent communication.\n\n* `ATL_BROKER_CLIENT_URI`\n\n The ActiveMQ Broker Client URI that remote agents will use to attempt to establish a connection to the ActiveMQ Broker on the Bamboo server.\n\n* `ATL_BAMBOO_SKIP_CONFIG` (defaults to `False`)\n\n If `true` skip the generation of `bamboo.cfg.xml`. This is only really useful\n for Bamboo versions >= 8.1, which added environment-based configuration (see\n next section).\n\n#### Optional configuration pre-seeding\n\nOptionally, for new deployments, the setup flow can be skipped by provided the\nrequired values via the environment. NOTE: This only work with Bamboo versions >= 8.1.\n\n* `SECURITY_TOKEN`\n\n The security token to use for server/agent authentication. Additional details\n [are available here](https://confluence.atlassian.com/bamboo/agent-authentication-289277196.html#Agentauthentication-SecuritytokenverificationSecuritytokenverification)\n\n* `ATL_BAMBOO_DISABLE_AGENT_AUTH` (default: false)\n\n Whether to disable agent authentication. Defaults to false.\n\n* `ATL_LICENSE`\n\n The licence to supply. Licenses can be generated at .\n\n* `ATL_BASE_URL`\n\n Bamboo instance Base URL.\n\n* `ATL_ADMIN_USERNAME`\n* `ATL_ADMIN_PASSWORD`\n* `ATL_ADMIN_FULLNAME`\n* `ATL_ADMIN_EMAIL`\n\nThe admin details and credentials.\n\n* `ATL_IMPORT_OPTION`\n \n Import data from backup file during setup. Default value is 'clean' which skip import step and create Bamboo home \n from scratch. If value is 'import' then `ATL_IMPORT_PATH` should contain path to backup archive.\n\n* `ATL_IMPORT_PATH`\n\n Full path to backup archive. \n \n### Database configuration\n\nIt is optionally possible to configure the database from the environment,\nwhich will pre-fill it for the installation wizard. The password cannot be pre-filled.\n\nThe following variables are all must all be supplied if using this feature:\n\n* `ATL_JDBC_URL`\n\n The database URL; this is database-specific.\n\n* `ATL_JDBC_USER`\n\n The database user to connect as.\n\n* `ATL_JDBC_PASSWORD`\n\n The database user password to connect with.\n\n* `ATL_DB_TYPE`\n\n The type of database; valid supported values are:\n\n * `h2` - for evaluation needs only\n * `mssql`\n * `mysql`\n * `oracle`\n * `postgresql`\n\n???+ note \"MySQL or Oracle JDBC drivers\" \n Due to licensing restrictions Bamboo does not ship with a MySQL or Oracle JDBC drivers (since Bamboo 7.0). \n To use these databases you will need to copy a suitable driver into the container and restart it. \n For example, to copy the MySQL driver into a container named \"bamboo\", you would do the following:\n\n `docker cp mysql-connector-java.x.y.z.jar bambooo:/opt/atlassian/bamboo/lib`\n\n `docker restart bamboo` \n\n#### Optional database settings\n\nThe following variables are for the database connection pool, and are\noptional.\n\n* `ATL_DB_POOLMINSIZE` (default: 3)\n* `ATL_DB_POOLMAXSIZE` (default: 170)\n* `ATL_DB_TIMEOUT` (default: 120000)\n* `ATL_DB_CONNECTIONTIMEOUT` (default: 30000)\n* `ATL_DB_LEAKDETECTION` (default: 0 / disabled)\n\n### Container Configuration\n\n* `ATL_FORCE_CFG_UPDATE` (default: false)\n\n The Docker [entrypoint][entrypoint.py] generates application configuration on\n first start; not all of these files are regenerated on subsequent\n starts. This is deliberate, to avoid race conditions or overwriting manual\n changes during restarts and upgrades. However in deployments where\n configuration is purely specified through the environment (e.g. Kubernetes)\n this behaviour may be undesirable; this flag forces an update of all\n generated files.\n \n In Bamboo the affected files are: `unattended-setup.properties`, `bamboo.cfg.xml`\n \n See [the entrypoint code][entrypoint.py] for the details of how configuration\n files are generated.\n\n* `ATL_ALLOWLIST_SENSITIVE_ENV_VARS`\n\n Define a comma separated list of environment variables containing keywords 'PASS', 'SECRET' or 'TOKEN' to be ignored by the unset function which is executed in the entrypoint. The function uses `^` regex. For example, if you set `ATL_ALLOWLIST_SENSITIVE_ENV_VARS=\"PATH_TO_SECRET_FILE\"`, all variables starting with `PATH_TO_SECRET_FILE` will not be unset.\n\n???+ warning \"Value exposure on host OS\"\n When using this property, the values to sensitive environment variables will be available in clear text on the host\n OS. As such, this data may be exposed to users or processes running on the host OS.\n\n* `SET_PERMISSIONS` (default: true)\n\n Define whether to set home directory permissions on startup. Set to `false` to disable this behaviour.\n\n## File system permissions and user IDs\n\nBy default, the Bamboo application runs as the user `bamboo`, with a UID\nand GID of 2005. Bamboo this UID must have write access to the home directory\nfilesystem. If for some reason a different UID must be used, there are a number\nof options available:\n\n* The Docker image can be rebuilt with a different UID.\n* Under Linux, the UID can be remapped using\n [user namespace remapping](https://docs.docker.com/engine/security/userns-remap/).\n\n## Upgrade\n\nTo upgrade to a more recent version of Bamboo you can simply stop the `bamboo` container and start a new one based on a more recent image:\n\n```shell\ndocker stop bamboo\ndocker rm bamboo\ndocker run ... (See above)\n```\n\nAs your data is stored in the data volume directory on the host it will still be available after the upgrade.\n\n!!! note \"Please make sure that you **don't** accidentally remove the `bamboo` container and its volumes using the `-v` option.\"\n\n## Backup\n\nFor evaluations you can use the built-in database that will store its files in the Bamboo home directory. In that case it is sufficient to create a backup archive of the docker volume.\n\nIf you're using an external database, you can configure Bamboo to make a backup automatically each night. This will back up the current state, including the database to the `bambooVolume` docker volume, which can then be archived. Alternatively you can backup the database separately, and continue to create a backup archive of the docker volume to back up the Bamboo Home directory.\n\nRead more about data recovery and backups: \n\n## Shutdown\n\nDepending on your configuration Bamboo may take a short period to shutdown any\nactive operations to finish before termination. If sending a `docker stop` this\nshould be taken into account with the `--time` flag.\n\nAlternatively, the script `/shutdown-wait.sh` is provided, which will initiate a\nclean shutdown and wait for the process to complete. This is the recommended\nmethod for shutdown in environments which provide for orderly shutdown,\ne.g. Kubernetes via the `preStop` hook.\n\n## Versioning\n\nThe `latest` tag matches the most recent release of Atlassian Bamboo. Thus\n`atlassian/bamboo:latest` will use the newest version of Bamboo available.\n\nAlternatively you can use a specific major, major.minor, or major.minor.patch\nversion of Bamboo by using a version number tag:\n\n* `atlassian/bamboo:9`\n* `atlassian/bamboo:9.6`\n* `atlassian/bamboo:9.6.8`\n\nAll versions from 8.0+ are available. Legacy builds for older versions are\navailable but are no longer supported.\n\n## Supported JDK versions and base images\n\nBamboo Docker images are based on JDK 11, JDK 17 (from Bamboo 9.4), and JDK 21 (from Bamboo 10.1) and generated from the\n[official Eclipse Temurin OpenJDK Docker images](https://hub.docker.com/_/eclipse-temurin) and \n[Red Hat Universal Base Images](https://catalog.redhat.com/software/containers/ubi9/openjdk-17/61ee7c26ed74b2ffb22b07f6?architecture=amd64).\nStarting in Bamboo 9.4, UBI tags are available in 2 formats: `-ubi9`, `-ubi9-jdk17`, `-ubi9-jdk21`\n\nThe Docker images follow the [Atlassian Support end-of-life\npolicy](https://confluence.atlassian.com/support/atlassian-support-end-of-life-policy-201851003.html);\nimages for unsupported versions of the products remain available but will no longer\nreceive updates or fixes.\n\nHowever, Bamboo is an exception to this. Due to the need to support JDK 11 and\nKubernetes, we currently only generate new images for Bamboo 9.1 and up. Legacy\nbuilds for JDK 8 are still available in Docker Hub, and building custom images\nis available (see below).\n\nHistorically, we have also generated other versions of the images, including\nJDK 8, Alpine, and 'slim' versions of the JDK. These legacy images still exist in\nDocker Hub, however they should be considered deprecated, and do not receive\nupdates or fixes.\n\nIf for some reason you need a different version, see \"Building your own image\".\n\n## Building your own image\n\n* Clone the Atlassian repository at \n* Modify or replace the [Jinja](https://jinja.palletsprojects.com/) templates\n under `config`; _NOTE_: The files must have the `.j2` extensions. However, you\n don't have to use template variables if you don't wish.\n* Build the new image with e.g: `docker build --tag my-bamboo-image --platform linux/amd64,linux/arm64 --build-arg BAMBOO_VERSION=X.Y.Z .`\n* Optionally push to a registry, and deploy.\n\n## Migration to UBI\n\nIf you have been mounting any files to `${JAVA_HOME}` directory in `eclipse-temurin` based container, `JAVA_HOME` in UBI container is set to `/usr/lib/jvm/java-17` (JDK17) and `/usr/lib/jvm/java-21` (JDK21).\n\nAlso, if you have been mounting and running any custom scripts in the container, UBI-based images may lack some tools and utilities that are available out of the box in eclipse-temurin tags. If that's the case, see [Building your own image](#building-your-own-image).\n\n## Supported architectures\n\nCurrently, the Atlassian Docker images are built for the `linux/amd64` and `linux/arm64` target\nplatforms; we do not have other architectures on our roadmap at this\npoint. However, the Dockerfiles and support tooling have now had all\narchitecture-specific components removed, so if necessary it is possible to\nbuild images for any platform supported by Docker.\n\n### Building on the target architecture\n\nThe simplest method of getting a platform image is to build it on a target\nmachine; and specify either `linux/amd64` or `linux/arm64`. See [Building your own image](#building-your-own-image) above.\n\nNote: This method is known to work on Mac M1 and AWS ARM64 machines, but has not\nbeen extensively tested.\n\n## Troubleshooting\n\nThese images include built-in scripts to assist in performing common JVM diagnostic tasks.\n\n### Thread dumps\n\n`/opt/atlassian/support/thread-dumps.sh` can be run via `docker exec` to easily trigger the collection of thread\ndumps from the containerized application. For example:\n\n```shell\ndocker exec my_container /opt/atlassian/support/thread-dumps.sh\n```\n\nBy default this script will collect 10 thread dumps at 5 second intervals. This can\nbe overridden by passing a custom value for the count and interval, by using `-c` / `--count`\nand `-i` / `--interval` respectively. For example, to collect 20 thread dumps at 3 second intervals:\n\n```shell\ndocker exec my_container /opt/atlassian/support/thread-dumps.sh --count 20 --interval 3\n```\n\nThread dumps will be written to `$APP_HOME/thread_dumps/`.\n\n???+ note \"Disable capturing output from top run\"\n By default this script will also capture output from top run in 'Thread-mode'. \n This can be disabled by passing `-n` / `--no-top`\n\n### Heap dump\n\n`/opt/atlassian/support/heap-dump.sh` can be run via `docker exec` to easily trigger the collection of a heap\ndump from the containerized application. For example:\n\n```shell\ndocker exec my_container /opt/atlassian/support/heap-dump.sh\n```\n\nA heap dump will be written to `$APP_HOME/heap.bin`. If a file already exists at this\nlocation, use `-f` / `--force` to overwrite the existing heap dump file.\n\n### Manual diagnostics\n\nThe `jcmd` utility is also included in these images and can be used by starting a `bash` shell\nin the running container:\n\n```shell\ndocker exec -it my_container /bin/bash\n```\n\n## Support\n\nFor product support, go to \n\nYou can also visit the [Atlassian Data Center](https://community.atlassian.com/t5/Atlassian-Data-Center-on/gh-p/DC_Kubernetes)\nforum for discussion on running Atlassian Data Center products in containers.\n\n## Changelog\n\nFor a detailed list of changes to the Docker image configuration see [the Git\ncommit history](https://bitbucket.org/atlassian-docker/docker-bamboo-server/commits/).\n\n## License\n\nCopyright © 2020 Atlassian Corporation Pty Ltd.\nLicensed under the Apache License, Version 2.0.\n\n[docker-expose]: https://docs.docker.com/v17.09/engine/userguide/networking/default_network/binding/\n[entrypoint.py]: https://bitbucket.org/atlassian-docker/docker-bamboo-server/src/master/entrypoint.py\n[encrypting-passwords-in-server]: https://confluence.atlassian.com/display/BAMBOO/Encrypting+passwords+in+server.xml\n" }, { "path": "docs/docs/containers/BITBUCKET-MESH.md", "content": "# ![Atlassian Bitbucket Mesh](https://wac-cdn.atlassian.com/dam/jcr:bf39fc40-3871-491f-98e3-fb2293f57a00/bitbucket-icon-gradient-blue.svg?cdnVersion=696){: style=\"height:35px;width:35px\"} Bitbucket Mesh\n\n## Overview\n\nBitbucket Data Center is an on-premises source code management solution for Git\nthat's secure, fast, and enterprise grade. Create and manage repositories, set\nup fine-grained permissions, and collaborate on code - all with the flexibility\nof your servers.\n\nBitbucket Mesh is an optional scalability extension for Bitbucket. For more\ninformation see .\n\nThis Docker image is published as `atlassian/bitbucket-mesh`.\n\nThis Docker container makes it easy to get Mesh nodes for a Bitbucket Data\nCenter up and running. It will only work in conjunction with a Bitbucket Data\nCenter server.\n\nFor full documentation on running Bitbucket Data Center with Mesh nodes, see [the\nBitbucket documentation](https://confluence.atlassian.com/bitbucketserver/bitbucket-mesh-1128304351.html).\n\n_* If running this image in a production environment, we strongly recommend you\nrun this image using a specific version tag instead of latest. This is because\nthe image referenced by the latest tag changes often and we cannot guarantee\nthat it will be backwards compatible. *_\n\n**Use docker version >= 20.10.10**\n\n## Quick Start\n\nFor the `MESH_HOME` directory that is used to store the repository data (amongst\nother things) we recommend mounting a host directory as a\n[data volume](https://docs.docker.com/engine/tutorials/dockervolumes/#/data-volumes),\nor via a named volume.\n\nVolume permissions are managed by entry scripts. To get started you can use a\ndata volume, or named volumes. In this example we'll use named volumes.\n```shell\ndocker volume create --name bitbucketMeshVolume\ndocker run -v bitbucketMeshVolume:/var/atlassian/application-data/mesh --name=\"bitbucket-mesh\" -d -p 7777:7777 atlassian/bitbucket-mesh\n```\n\nNote that this command can substitute folder paths with named volumes.\n\nPlease ensure your container has the necessary resources allocated to it.\nWe recommend 2GiB of memory allocated to accommodate both the application server\nand the git processes.\nSee [Supported Platforms](https://confluence.atlassian.com/display/BitbucketServer/Supported+platforms) for further information.\n\n\n## Common settings\n\n### Verbose container entrypoint logging\n\nDuring the startup process of the container, various operations and checks are performed to ensure that the application\nis configured correctly and ready to run. To help in troubleshooting and to provide transparency into this process, you\ncan enable verbose logging. The `VERBOSE_LOGS` environment variable enables detailed debug messages to the container's \nlog, offering insights into the actions performed by the entrypoint script.\n\n* `VERBOSE_LOGS` (default: false)\n\n Set to `true` to enable detailed debug messages during the container initialization.\n\n### Mesh Node Configuration\n\n* `MESH_HOME`\n\n The home directory used by the Mesh node. This should have full read/write\n permissions and be persistent – your Bitbucket Mesh data will be stored here.\n\n* `GRPC_SERVER_PORT` (default: 7777)\n\n The port used by the Mesh node to communicate with the server.\n\n### Mesh Node JVM Configuration\n\nIf you need to override the Mesh node's default memory configuration or pass\nadditional JVM arguments, use the environment variables below\n\n* `JVM_MINIMUM_MEMORY` (default: 512m)\n\n The minimum heap size of the JVM\n\n* `JVM_MAXIMUM_MEMORY` (default: 1024m)\n\n The maximum heap size of the JVM\n\n* `JVM_SUPPORT_RECOMMENDED_ARGS` (default: NONE)\n\n Additional JVM arguments for the Mesh node , such as a custom Java Trust Store\n\n### JMX Monitoring\n\nJMX monitoring can be enabled with `JMX_ENABLED=true`. Information\non additional settings and available metrics is available in the\n[Bitbucket JMX documentation](https://confluence.atlassian.com/bitbucketserver/enabling-jmx-counters-for-performance-monitoring-776640189.html).\n\n## Other settings\n\nAs well as the above settings, all settings that are available in the\n[mesh.properties file](https://confluence.atlassian.com/bitbucketserver/mesh-configuration-properties-1128304362.html)\ncan also be provided via Docker environment variables. For a full explanation of converting Bitbucket properties into environment\nvariables see\n[the relevant Spring Boot documentation](https://docs.spring.io/spring-boot/docs/current/reference/html/boot-features-external-config.html#boot-features-external-config-relaxed-binding).\n\nTo translate a property name into an environment variable:\n\n* dot `.` becomes underscore `_`\n* dash `-` becomes underscore `_`\n* Example: `this.new-property` becomes `THIS_NEW_PROPERTY`\n\n## Container Configuration\n\n* `SET_PERMISSIONS` (default: true)\n\n Define whether to set home directory permissions on startup. Set to `false` to disable\n this behaviour.\n\n## Home directory and user IDs\n\nBy default the Bitbucket application runs as the user `bitbucket`, with a UID\nand GID of 2003. If for some reason a different UID must be used, there are a\nnumber of options available:\n\n* The Docker image can be rebuilt with a different UID.\n* Under Linux, the UID can be remapped using\n [user namespace remapping](https://docs.docker.com/engine/security/userns-remap/).\n\n## Shutdown\n\nThe Mesh node allows a configurable grace period for active operations to finish\nbefore termination; by default this is 30s. If sending a `docker stop` this\nshould be taken into account with the `--time` flag.\n\nAlternatively, the script `/shutdown-wait.sh` is provided, which will initiate a\nclean shutdown and wait for the process to complete. This is the recommended\nmethod for shutdown in environments which provide for orderly shutdown,\ne.g. Kubernetes via the `preStop` hook.\n\n## Versioning\n\nYou should ensure you are running the appropriate Mesh version for your\nBitbucket Data Center server. A support matrix is available here:\n[Bitbucket Mesh compatibility matrix](https://confluence.atlassian.com/bitbucketserver/bitbucket-mesh-compatibility-matrix-1127254859.html).\n\n## Supported JDK versions and base images\n\nThe Bitbucket Mesh Docker images support the following JDK versions:\n\n* **JDK 11**: Supported for Mesh versions 2.0.1 to 3.0.0\n* **JDK 17**: Supported for Mesh versions 2.4 to 3.4.5\n* **JDK 21**: Supported for Mesh versions 3.4.5 and above (required for Mesh 4.x)\n\nImages are generated from the [official Eclipse Temurin OpenJDK Docker images](https://hub.docker.com/_/eclipse-temurin).\n\nStarting from 2.4, [UBI based](https://catalog.redhat.com/software/containers/ubi9/openjdk-17/61ee7c26ed74b2ffb22b07f6?architecture=amd64) tags are published as well.\nUBI tags are available in the following formats:\n* For JDK 17: `-ubi9` and `-ubi9-jdk17`\n* For JDK 21: `-ubi9` and `-ubi9-jdk21` (from version 3.4.5)\n\nThe Docker images follow the [Atlassian Support end-of-life\npolicy](https://confluence.atlassian.com/support/atlassian-support-end-of-life-policy-201851003.html);\nimages for unsupported versions of the products remain available but will no longer\nreceive updates or fixes.\n\nIf for some reason you need a different version, see \"Building your own image\"\n\n## Migration to UBI\n\nIf you have been mounting any files to `${JAVA_HOME}` directory in `eclipse-temurin` based container, `JAVA_HOME` in UBI JDK17 container is set to `/usr/lib/jvm/java-17`.\n\nAlso, if you have been mounting and running any custom scripts in the container, UBI-based images may lack some tools and utilities that are available out of the box in eclipse-temurin tags. If that's the case, see \"Building your own image\".\n\n## Building your own image\n\n* Clone the Atlassian repository at https://bitbucket.org/atlassian-docker/docker-atlassian-bitbucket-mesh/\n* Modify or replace the [Jinja](https://jinja.palletsprojects.com/) templates\n under `config`; _NOTE_: The files must have the `.j2` extensions. However, you\n don't have to use template variables if you don't wish.\n* Build the new image with e.g: `docker build --tag my-bitbucket-mesh-image --build-arg MESH_VERSION=1.x.x .`\n* Optionally push to a registry, and deploy.\n\n## Supported architectures\n\nCurrently, Bitbucket Mesh container images are built for the `linux/amd64` and `linux/arm64` target platforms.\nThe Dockerfiles and support tooling have now had all\narchitecture-specific components removed, so if necessary it is possible to\nbuild images for any platform supported by OCI-compliant container runtimes.\n\n## Building on the target architecture\n\nThe simplest method of getting a platform image is to build it on a target\nmachine; see \"Building your own image\" above.\n\nNote: This method is known to work on Mac M1 and AWS ARM64 machines, but has not\nbe extensively tested.\n\n## Troubleshooting\n\nThese images include built-in scripts to assist in performing common JVM diagnostic tasks.\n\n### Thread dumps\n\n`/opt/atlassian/support/thread-dumps.sh` can be run via `docker exec` to easily trigger the collection of thread\ndumps from the containerized application. For example:\n```shell\ndocker exec my_container /opt/atlassian/support/thread-dumps.sh\n```\n\nBy default, this script will collect 10 thread dumps at 5 second intervals. This can\nbe overridden by passing a custom value for the count and interval, by using `-c` / `--count`\nand `-i` / `--interval` respectively. For example, to collect 20 thread dumps at 3 second intervals:\n```shell\ndocker exec my_container /opt/atlassian/support/thread-dumps.sh --count 20 --interval 3\n```\n\nThread dumps will be written to `$APP_HOME/thread_dumps/`.\n\n???+ note \"Disable capturing output from top run\"\n By default this script will also capture output from top run in 'Thread-mode'. This can\n be disabled by passing `-n` / `--no-top`\n\n### Heap dump\n\n`/opt/atlassian/support/heap-dump.sh` can be run via `docker exec` to easily trigger the collection of a heap\ndump from the containerized application. For example:\n```shell\ndocker exec my_container /opt/atlassian/support/heap-dump.sh\n```\n\nA heap dump will be written to `$APP_HOME/heap.bin`. If a file already exists at this\nlocation, use `-f` / `--force` to overwrite the existing heap dump file.\n\n## Manual diagnostics\n\nThe `jcmd` utility is also included in these images and can be used by starting a `bash` shell\nin the running container:\n```shell\ndocker exec -it my_container /bin/bash\n```\n\n## Support\n\nFor product support, go to [support.atlassian.com](https://support.atlassian.com/)\n\nYou can also visit the [Atlassian Data Center](https://community.atlassian.com/t5/Atlassian-Data-Center-on/gh-p/DC_Kubernetes)\nforum for discussion on running Atlassian Data Center products in containers.\n\n# Changelog\n\nFor a detailed list of changes to the Docker image configuration see [the Git\ncommit history](https://bitbucket.org/atlassian-docker/docker-atlassian-bitbucket-mesh/commits/).\n\n# License\n\nCopyright © 2022 Atlassian Corporation Pty Ltd.\nLicensed under the Apache License, Version 2.0.\n" }, { "path": "docs/docs/containers/BITBUCKET.md", "content": "# ![Atlassian Bitbucket Server](https://wac-cdn.atlassian.com/dam/jcr:bf39fc40-3871-491f-98e3-fb2293f57a00/bitbucket-icon-gradient-blue.svg?cdnVersion=696){: style=\"height:35px;width:35px\"} Bitbucket\n\n!!! warning \"Server image deprecation\"\n This Docker image has been published as both `atlassian/bitbucket` and `atlassian/bitbucket-server` up until February 15, 2024.\n Both names refer to the same image. However, post-February 15, 2024, the `atlassian/bitbucket-server` version ceased \n receiving updates, including both existing and new tags. If you have been using `atlassian/bitbucket-server`, \n switch to the `atlassian/bitbucket` image to ensure access to the latest updates and new tags.\n\n\n## Overview\n\nBitbucket Server is an on-premises source code management solution for Git\nthat's secure, fast, and enterprise grade. Create and manage repositories, set\nup fine-grained permissions, and collaborate on code - all with the flexibility\nof your servers.\n\nLearn more about Bitbucket Server: \n\nThis Docker container makes it easy to get an instance of Bitbucket up and\nrunning.\n\n???+ note \"Embedded OpenSearch\"\n Only Bitbucket versions < 10 include an embedded search server.\n For backwards-compatibility, by default the image will start both Bitbucket and an embedded OpenSearch. \n However, this is not a recommended configuration, especially in a clustered environment, and has known issues with\n shutdown. Instead, we recommend running a separate OpenSearch instance (possibly in another Docker container); \n see below for instructions on connecting to an external OpenSearch cluster.\n\n_* If running this image in a production environment, we strongly recommend you\nrun this image using a specific version tag instead of latest. This is because\nthe image referenced by the latest tag changes often and we cannot guarantee\nthat it will be backwards compatible. *_\n\n**Use docker version >= 20.10.10**\n\n## Quick Start\n\nFor the `BITBUCKET_HOME` directory that is used to store the repository data\n(amongst other things) we recommend mounting a host directory as a\n[data volume](https://docs.docker.com/engine/tutorials/dockervolumes/#/data-volumes),\nor via a named volume.\n\nAdditionally, if running Bitbucket in Data Center mode it is required that a shared filesystem is mounted.\n\nVolume permission is managed by entry scripts. To get started you can use a data\nvolume, or named volumes. In this example we'll use named volumes.\n```shell\ndocker volume create --name bitbucketVolume\ndocker run -v bitbucketVolume:/var/atlassian/application-data/bitbucket --name=\"bitbucket\" -d -p 7990:7990 -p 7999:7999 atlassian/bitbucket\n```\nNote that this command can substitute folder paths with named volumes. Start Atlassian Bitbucket Server:\n```shell\ndocker run -v /data/bitbucket:/var/atlassian/application-data/bitbucket --name=\"bitbucket\" -d -p 7990:7990 -p 7999:7999 atlassian/bitbucket\n```\n!!! success \"Bitbucket is now available on .\"\n\nPlease ensure your container has the necessary resources allocated to it.\nWe recommend 2GiB of memory allocated to accommodate both the application server\nand the git processes.\nSee [Supported Platforms](https://confluence.atlassian.com/display/BitbucketServer/Supported+platforms) for further information.\n\n???+ tip \"If you are using `docker-machine` on Mac OS X, please use `open http://$(docker-machine ip default):7990` instead.\"\n\n## Common settings\n\n### Verbose container entrypoint logging\n\nDuring the startup process of the container, various operations and checks are performed to ensure that the application\nis configured correctly and ready to run. To help in troubleshooting and to provide transparency into this process, you\ncan enable verbose logging. The `VERBOSE_LOGS` environment variable enables detailed debug messages to the container's\nlog, offering insights into the actions performed by the entrypoint script.\n\n* `VERBOSE_LOGS` (default: false)\n\n Set to `true` to enable detailed debug messages during the container initialization.\n\n### Reverse Proxy Settings\n\nIf Bitbucket is run behind a reverse proxy server as\n[described here](https://confluence.atlassian.com/bitbucketserver/proxying-and-securing-bitbucket-server-776640099.html),\nthen you need to specify extra options to make Bitbucket aware of the\nsetup. They can be controlled via the below environment variables.\n\n* `SERVER_PROXY_NAME` (default: NONE)\n\n The reverse proxy's fully qualified hostname.\n\n* `SERVER_PROXY_PORT` (default: NONE)\n\n The reverse proxy's port number via which bitbucket is accessed.\n\n* `SERVER_SCHEME` (default: http)\n\n The protocol via which bitbucket is accessed. \n \n In certain cloud environments (specifically Kubernetes, Heroku and Cloud Foundry), this setting\n will be superseded by the value of the `X-Forwarded-Proto` request header if sent by a ingress or load balancer. \n See `SERVER_FORWARD_HEADERS_STRATEGY` below to alter this behaviour.\n\n* `SERVER_SECURE` (default: false)\n\n Set 'true' if SERVER\\_SCHEME is 'https'. \n\n* `SERVER_FORWARD_HEADERS_STRATEGY` (default: NATIVE in the specified cloud environments, NONE otherwise)\n\n Can be explicitly set to a value of `NONE` if deploying to a cloud environment (specifically Kubernetes, Heroku and Cloud Foundry) and the preference is for `SERVER_SCHEME` \n to be used over the value of the `X-Forwarded-Proto` request header. A value of NONE will cause X-Forwarded-* headers to no longer take priority when determining the \n origin of a request, which means the system will return to the default expected state.\n\n### JVM Configuration (Bitbucket Server 5.0 + only)\n\nIf you need to override Bitbucket Server's default memory configuration or pass\nadditional JVM arguments, use the environment variables below\n\n* `JVM_MINIMUM_MEMORY` (default: 512m)\n\n The minimum heap size of the JVM\n\n* `JVM_MAXIMUM_MEMORY` (default: 1024m)\n\n The maximum heap size of the JVM\n\n* `JVM_SUPPORT_RECOMMENDED_ARGS` (default: NONE)\n\n Additional JVM arguments for Bitbucket Server, such as a custom Java Trust Store\n\n### Application Mode Settings (Bitbucket Server 5.0 + only)\n\nThis docker image can be run as a\n[Smart Mirror](https://confluence.atlassian.com/bitbucketserver/smart-mirroring-776640046.html)\nor as part of a\n[Data Center](https://confluence.atlassian.com/enterprise/bitbucket-data-center-668468332.html)\ncluster. You can specify the following properties to start Bitbucket as a\nmirror or as a Data Center node:\n\n* `SEARCH_ENABLED` (default: true)\n \n Note: This property is not applicable for Bitbucket 10.0.0 onwards, as embedded search was removed in Bitbucket 10.
\n Set 'false' to prevent OpenSearch (previously Elasticsearch) from starting in the\n container. This should be used if OpenSearch is running remotely, e.g. for if Bitbucket\n is running in a Data Center cluster. You may also use `ELASTICSEARCH_ENABLED` to\n set this property, however this is deprecated in favor of `SEARCH_ENABLED`.\n\n* `APPLICATION_MODE` (default: default)\n\n The mode Bitbucket will run in. This can be set to 'mirror' to start\n Bitbucket as a Smart Mirror. This will also disable OpenSearch even if\n `SEARCH_ENABLED` has not been set to 'false'.\n\n### Database Configuration\n\nTo configure the database automatically on first run, you can provide the\nfollowing settings:\n\n* `JDBC_DRIVER`\n* `JDBC_URL`\n* `JDBC_USER`\n* `JDBC_PASSWORD`\n\nNote: Due to licensing restrictions Bitbucket does not ship with a MySQL or\nOracle JDBC drivers. To use these databases you will need to copy a suitable\ndriver into the container and restart it. For example, to copy the MySQL driver\ninto a container named \"bitbucket\", you would do the following:\n\n```shell\ndocker cp mysql-connector-java.x.y.z.jar bitbucket:/var/atlassian/application-data/bitbucket/lib\ndocker restart bitbucket\n```\n\nFor more information see [Connecting Bitbucket Server to an external database](https://confluence.atlassian.com/bitbucketserver/connecting-bitbucket-server-to-an-external-database-776640378.html).\n\n#### JDBC password encryption\n\nStarting from Bitbucket `8.13` the `JDBC` password can now be managed via [AWS Secrets Manager](https://confluence.atlassian.com/bitbucketserver/configuring-bitbucket-with-aws-secrets-manager-1279066293.html). For example, a Bitbucket node with a PostgreSQL database and `JDBC` password management via AWS Secrets Manager might look like:\n\n```shell\ndocker run \\\n -e JDBC_DRIVER=org.postgresql.Driver \\\n -e JDBC_USER=atlbitbucket \\\n -e JDBC_PASSWORD=\"{\\\"region\\\":\\\"us-east-1\\\",\\\"secretId\\\":\\\"mysecret\\\",\\\"secretPointer\\\":\\\"/password\\\"}\" \\\n -e JDBC_PASSWORD_DECRYPTER_CLASSNAME=\"com.atlassian.secrets.store.aws.AwsSecretsManagerStore\" \\\n -e JDBC_URL=jdbc:postgresql://my.database.host:5432/bitbucket \\\n -v /data/bitbucket-shared:/var/atlassian/application-data/bitbucket/shared \\\n --name=\"bitbucket\" \\\n -d -p 7990:7990 -p 7999:7999 \\\n atlassian/bitbucket\n```\n\nOf note here are the two properties; `JDBC_PASSWORD` and `JDBC_PASSWORD_DECRYPTER_CLASSNAME` and their corresponding values, where the Secrets Manager coordinates and decryption class name are supplied respectively. \n\n## Other settings\n\nAs well as the above settings, all settings that are available in the\n[bitbucket.properties file](https://confluence.atlassian.com/bitbucketserver/bitbucket-server-config-properties-776640155.html)\ncan also be provided via Docker environment variables. For a full explanation of converting Bitbucket properties into environment\nvariables see\n[the relevant Spring Boot documentation](https://docs.spring.io/spring-boot/docs/current/reference/html/boot-features-external-config.html#boot-features-external-config-relaxed-binding).\n\nTo translate a property name into an environment variable:\n\n* dot `.` becomes underscore `_`\n* dash `-` becomes underscore `_`\n* Example: `this.new-property` becomes `THIS_NEW_PROPERTY`\n\nFor example, a full command-line for a Bitbucket node with a PostgreSQL\ndatabase, and an external OpenSearch instance might look like:\n\n```shell\ndocker network create --driver bridge --subnet=172.18.0.0/16 myBitbucketNetwork\ndocker run --network=myBitbucketNetwork --ip=172.18.1.1 \\\n -e SEARCH_ENABLED=false \\\n -e JDBC_DRIVER=org.postgresql.Driver \\\n -e JDBC_USER=atlbitbucket \\\n -e JDBC_PASSWORD=MYPASSWORDSECRET \\\n -e JDBC_URL=jdbc:postgresql://my.database.host:5432/bitbucket \\\n -e PLUGIN_SEARCH_CONFIG_BASEURL=http://my.opensearch.host \\\n -v /data/bitbucket-shared:/var/atlassian/application-data/bitbucket/shared \\\n --name=\"bitbucket\" \\\n -d -p 7990:7990 -p 7999:7999 \\\n atlassian/bitbucket\n```\n\n### Cluster settings\n\nIf running a clustered Bitbucket DC instance, the cluster settings are specified\nwith `HAZELCAST_*` environment variables. The main ones to be aware of are:\n\n* `HAZELCAST_PORT` (`hazelcast.port`)\n* `HAZELCAST_GROUP_NAME` (`hazelcast.group.name`)\n* `HAZELCAST_GROUP_PASSWORD` (`hazelcast.group.password`)\n\nEach clustering type (e.g. AWS/Azure/Multicast/TCP) has its own settings. For\nmore information on clustering Bitbucket, and other properties see\n[Clustering with Bitbucket Data Center](https://confluence.atlassian.com/bitbucketserver/clustering-with-bitbucket-data-center-776640164.html)\nand [Clustering with Bitbucket Data Center](https://confluence.atlassian.com/bitbucketserver/bitbucket-server-config-properties-776640155.html).\n\n???+ note \"Out-of-scope network configuration\"\n The underlying network should be configured to support the clustering type you are using. How to do this depends on\n the container management technology, and is beyond the scope of this documentation.\n\n### JMX Monitoring\n\nJMX monitoring can be enabled with `JMX_ENABLED=true`. Information\non additional settings and available metrics is available in the\n[Bitbucket JMX documentation](https://confluence.atlassian.com/bitbucketserver/enabling-jmx-counters-for-performance-monitoring-776640189.html).\n\n## Container Configuration\n\n* `SET_PERMISSIONS` (default: true)\n\n Define whether to set home directory permissions on startup. Set to `false` to disable\n this behaviour.\n\n## Shared directory and user IDs\n\nBy default the Bitbucket application runs as the user `bitbucket`, with a UID\nand GID of 2003. Consequently this UID must have write access to the shared\nfilesystem. If for some reason a different UID must be used, there are a number\nof options available:\n\n* The Docker image can be rebuilt with a different UID.\n* Under Linux, the UID can be remapped using\n [user namespace remapping](https://docs.docker.com/engine/security/userns-remap/).\n\n## Upgrade\n\nTo upgrade to a more recent version of Bitbucket Server you can simply stop the `bitbucket`\ncontainer and start a new one based on a more recent image:\n\n```shell\ndocker stop bitbucket\ndocker rm bitbucket\ndocker pull atlassian/bitbucket:\ndocker run ... (See above)\n```\n\nAs your data is stored in the data volume directory on the host it will still\nbe available after the upgrade.\n\n!!! note \"Please make sure that you **don't** accidentally remove the `bitbucket` container and its volumes using the `-v` option.\"\n\n## Backup\n\nFor evaluations you can use the built-in database that will store its files in\nthe Bitbucket Server home directory. In that case it is sufficient to create a\nbackup archive of the directory on the host that is used as a volume\n(`/data/bitbucket` in the example above).\n\nThe [Bitbucket Server Backup Client](https://confluence.atlassian.com/display/BitbucketServer/Data+recovery+and+backups)\nis currently not supported in the Docker setup. You can however use the\n[Bitbucket Server DIY Backup](https://confluence.atlassian.com/display/BitbucketServer/Using+Bitbucket+Server+DIY+Backup)\napproach in case you decided to use an external database.\n\nRead more about data recovery and backups:\n[https://confluence.atlassian.com/display/BitbucketServer/Data+recovery+and+backups](https://confluence.atlassian.com/display/BitbucketServer/Data+recovery+and+backups)\n\n## Shutdown\n\nBitbucket allows a configurable grace period for active operations to finish\nbefore termination; by default this is 30s. If sending a `docker stop` this\nshould be taken into account with the `--time` flag.\n\nAlternatively, the script `/shutdown-wait.sh` is provided, which will initiate a\nclean shutdown and wait for the process to complete. This is the recommended\nmethod for shutdown in environments which provide for orderly shutdown,\ne.g. Kubernetes via the `preStop` hook.\n\n## Versioning\n\nThe `latest` tag matches the most recent version of this repository. Thus using\n`atlassian/bitbucket:latest` or `atlassian/bitbucket` will ensure you are\nrunning the most up to date version of this image.\n\nAlternatively, you can use a specific minor version of Bitbucket Server by\nusing a version number tag: `atlassian/bitbucket:6`. This will\ninstall the latest `6.x.x` version that is available.\n\n## Supported JDK versions and base images\n\nAll the Atlassian Docker images are now JDK11 and JDK17 (starting from 8.8 version), and generated from the\n[official Eclipse Temurin OpenJDK Docker images](https://hub.docker.com/_/eclipse-temurin).\n\nStarting from 8.18 [UBI based](https://catalog.redhat.com/software/containers/ubi9/openjdk-17/61ee7c26ed74b2ffb22b07f6?architecture=amd64) tags are published as well.\nUBI tags are available in 2 formats: `-ubi9` and `-ubi9-jdk17`.\n\nThe Docker images follow the [Atlassian Support end-of-life\npolicy](https://confluence.atlassian.com/support/atlassian-support-end-of-life-policy-201851003.html);\nimages for unsupported versions of the products remain available but will no longer\nreceive updates or fixes.\n\nHistorically, we have also generated other versions of the images, including\nJDK8, Alpine, and 'slim' versions of the JDK. These legacy images still exist in\nDocker Hub, however they should be considered deprecated, and do not receive\nupdates or fixes.\n\nIf for some reason you need a different version, see \"Building your own image\"\n\n## Migration to UBI\n\nIf you have been mounting any files to `${JAVA_HOME}` directory in `eclipse-temurin` based container, JAVA_HOME in UBI JDK17 container is set to `/usr/lib/jvm/java-17`.\n\nAlso, if you have been mounting and running any custom scripts in the container, UBI-based images may lack some tools and utilities that are available out of the box in `eclipse-temurin` tags. If that's the case, see [Building your own image](#building-your-own-image).\n\n## Building your own image\n\n* Clone the Atlassian repository at https://bitbucket.org/atlassian-docker/docker-atlassian-bitbucket-server/\n* Modify or replace the [Jinja](https://jinja.palletsprojects.com/) templates\n under `config`; _NOTE_: The files must have the `.j2` extensions. However, you\n don't have to use template variables if you don't wish.\n* Build the new image with e.g: `docker build --tag my-bitbucket-image --build-arg BITBUCKET_VERSION=8.x.x .`\n* Optionally push to a registry, and deploy.\n\n## Supported architectures\n\nCurrently, Bitbucket container images are built for the `linux/amd64` and `linux/arm64` target platforms.\nThe Dockerfiles and support tooling have now had all\narchitecture-specific components removed, so if necessary it is possible to\nbuild images for any platform supported by OCI-compliant container runtimes.\n\n## Building on the target architecture\n\nThe simplest method of getting a platform image is to build it on a target\nmachine; see \"Building your own image\" above.\n\nNote: This method is known to work on Mac M1 and AWS ARM64 machines, but has not\nbeen extensively tested.\n\n## Troubleshooting\n\nThese images include built-in scripts to assist in performing common JVM diagnostic tasks.\n\n### Thread dumps\n\n`/opt/atlassian/support/thread-dumps.sh` can be run via `docker exec` to easily trigger the collection of thread\ndumps from the containerized application. For example:\n```shell\ndocker exec my_container /opt/atlassian/support/thread-dumps.sh\n```\n\nBy default, this script will collect 10 thread dumps at 5 second intervals. This can\nbe overridden by passing a custom value for the count and interval, by using `-c` / `--count`\nand `-i` / `--interval` respectively. For example, to collect 20 thread dumps at 3 second intervals:\n```shell\ndocker exec my_container /opt/atlassian/support/thread-dumps.sh --count 20 --interval 3\n```\n\nThread dumps will be written to `$APP_HOME/thread_dumps/`.\n\n???+ note \"Disable capturing output from top run\"\n By default this script will also capture output from top run in 'Thread-mode'. This can\n be disabled by passing `-n` / `--no-top`\n\n### Heap dump\n\n`/opt/atlassian/support/heap-dump.sh` can be run via `docker exec` to easily trigger the collection of a heap\ndump from the containerized application. For example:\n```shell\ndocker exec my_container /opt/atlassian/support/heap-dump.sh\n```\n\nA heap dump will be written to `$APP_HOME/heap.bin`. If a file already exists at this\nlocation, use `-f` / `--force` to overwrite the existing heap dump file.\n\n### Manual diagnostics\n\nThe `jcmd` utility is also included in these images and can be used by starting a `bash` shell\nin the running container:\n```shell\ndocker exec -it my_container /bin/bash\n```\n\n## Support\n\nFor product support, go to [support.atlassian.com](https://support.atlassian.com/)\n\nYou can also visit the [Atlassian Data Center](https://community.atlassian.com/t5/Atlassian-Data-Center-on/gh-p/DC_Kubernetes)\nforum for discussion on running Atlassian Data Center products in containers.\n\n## Changelog\n\nFor a detailed list of changes to the Docker image configuration see [the Git\ncommit history](https://bitbucket.org/atlassian-docker/docker-atlassian-bitbucket-server/commits/).\n\n## License\n\nCopyright © 2019 Atlassian Corporation Pty Ltd.\nLicensed under the Apache License, Version 2.0.\n" }, { "path": "docs/docs/containers/CONFLUENCE.md", "content": "# ![Atlassian Confluence Server](https://wac-cdn.atlassian.com/dam/jcr:5d1374c2-276f-4bca-9ce4-813aba614b7a/confluence-icon-gradient-blue.svg?cdnVersion=696){: style=\"height:35px;width:35px\"} Confluence\n\n!!! warning \"Server image deprecation\"\n This Docker image has been published as both `atlassian/confluence` and `atlassian/confluence-server` up until \n February 15, 2024. Both names refer to the same image. However, post-February 15, 2024, the \n `atlassian/confluence-server` version ceased receiving updates, including both existing and new tags. If you have \n been using `atlassian/confluence-server`, switch to the `atlassian/confluence` image to ensure access to the \n latest updates and new tags.\n\n## Overview\n\nConfluence Server is where you create, organise and discuss work with your team. Capture the knowledge that's too often\nlost in email inboxes and shared network drives in Confluence - where it's easy to find, use, and update. \nGive every team, project, or department its own space to create the things they need, whether it's meeting notes, \nproduct requirements, file lists, or project plans, you can get more done in Confluence.\n\nThis Docker container makes it easy to get an instance of Confluence up and running.\n\nLearn more about Confluence Server: \n\nYou can find the repository with the Dockerfile at \n\nDockerHub repository: \n\n**Use docker version >= 20.10.10**\n\n## Quick Start\n\nFor the directory in the environmental variable `CONFLUENCE_HOME` that is used\nto store Confluence data (amongst other things) we recommend mounting a host\ndirectory as a [data volume][1]:\n\nAdditionally, if running Confluence in Data Center mode it is required that a\nshared filesystem is mounted. The mountpoint (inside the container) can be\nconfigured with `CONFLUENCE_SHARED_HOME`.\n\nStart Atlassian Confluence Server:\n```shell\ndocker run -v /data/your-confluence-home:/var/atlassian/application-data/confluence --name=\"confluence\" -d -p 8090:8090 -p 8091:8091 atlassian/confluence\n```\n!!! success \"Confluence is now available on .\"\n\nPlease ensure your container has the necessary resources allocated to it. We\nrecommend 2GiB of memory allocated to accommodate the application server. See\n[Supported Platforms][3] for further information.\n\n???+ tip \"If you are using `docker-machine` on Mac OS X, please use `open http://$(docker-machine ip default):8090` instead.\"\n\n## Configuring Confluence\n\nThis Docker image is intended to be configured from its environment; the\nprovided information is used to generate the application configuration files\nfrom templates. This allows containers to be repeatably created and destroyed\non-the-fly, as required in advanced cluster configurations. Most aspects of the\ndeployment can be configured in this manner; the necessary environment variables\nare documented below. However, if your particular deployment scenario is not\ncovered by these settings, it is possible to override the provided templates\nwith your own; see the section [Advanced Configuration](#advanced-configuration) below.\n\n### Verbose container entrypoint logging\n\nDuring the startup process of the container, various operations and checks are performed to ensure that the application\nis configured correctly and ready to run. To help in troubleshooting and to provide transparency into this process, you\ncan enable verbose logging. The `VERBOSE_LOGS` environment variable enables detailed debug messages to the container's\nlog, offering insights into the actions performed by the entrypoint script.\n\n* `VERBOSE_LOGS` (default: false)\n\n Set to `true` to enable detailed debug messages during the container initialization.\n\n### Memory / Heap Size\n\nIf you need to override Confluence Server's default memory allocation, you can\ncontrol the minimum heap (Xms) and maximum heap (Xmx) via the below environment\nvariables.\n\n* `JVM_MINIMUM_MEMORY` (default: 1024m)\n\n The minimum heap size of the JVM\n\n* `JVM_MAXIMUM_MEMORY` (default: 1024m)\n\n The maximum heap size of the JVM\n\n* `JVM_RESERVED_CODE_CACHE_SIZE` (default: 256m)\n\n The reserved code cache size of the JVM\n\n### Tomcat and Reverse Proxy Settings\n\nIf Confluence is run behind a reverse proxy server (e.g. a load-balancer or\nnginx server), then you need to specify extra options to make Confluence aware\nof the setup. They can be controlled via the below environment variables.\n\n* `ATL_PROXY_NAME` (default: NONE)\n\n The reverse proxy's fully qualified hostname. `CATALINA_CONNECTOR_PROXYNAME`\n is also supported for backwards compatability.\n\n* `ATL_PROXY_PORT` (default: NONE)\n\n The reverse proxy's port number via which Confluence is\n accessed. `CATALINA_CONNECTOR_PROXYPORT` is also supported for backwards\n compatability.\n\n* `ATL_TOMCAT_PORT` (default: 8090)\n\n The port for Tomcat/Confluence to listen on. Depending on your container\n deployment method this port may need to be\n [exposed and published][docker-expose].\n\n* `ATL_TOMCAT_SCHEME` (default: http)\n\n The protocol via which Confluence is accessed. `CATALINA_CONNECTOR_SCHEME` is also\n supported for backwards compatability.\n\n* `ATL_TOMCAT_SECURE` (default: false)\n\n Set 'true' if `ATL_TOMCAT_SCHEME` is 'https'. `CATALINA_CONNECTOR_SECURE` is\n also supported for backwards compatability.\n\n* `ATL_TOMCAT_CONTEXTPATH` (default: NONE)\n\n The context path the application is served over. `CATALINA_CONTEXT_PATH` is\n also supported for backwards compatability.\n\n* `ATL_TOMCAT_ACCESS_LOG` (default: false [version < 7.11.0] and true [version >=7.11.0])\n\n Whether to enable Tomcat access logging; set to `true` to enable. *NOTE*:\n These logs are written to the Container internal volume by default (under\n `/opt/atlassian/confluence/logs/`); these are rotated but not removed, and\n will grow indefinitely. If you enable this functionality it is recommended\n that you map the directory to a volume and perform log ingestion/cleanup with\n external tools.\n\n* `ATL_TOMCAT_REQUESTATTRIBUTESENABLED`\n\n Checks for the existence of request attributes (typically set by the RemoteIpValve and similar)\n that should be used to override the values returned by the request for remote address,\n remote host, server port and protocol. This property is usually combined with `ATL_TOMCAT_TRUSTEDPROXIES`\n and `ATL_TOMCAT_INTERNALPROXIES` to show IP address of the remote host instead of the load balancer's.\n If not declared, the default value of `false` will be used.\n\n* `ATL_TOMCAT_TRUSTEDPROXIES`\n\n A list of IP addresses separated by a pipe character e.g. `10.0.9.6|10.0.9.32`. \n Trusted proxies that appear in the `remoteIpHeader` will be trusted and *will appear*\n in the `proxiesHeader` value. By adding a list of Trusted Proxies, Confluence will remove the\n load balancers' IP addresses from Confluence's view of the incoming connection. This could be desired\n in a clustered load balancer architecture where the load balancer address changes depending on\n which node proxies the connection.\n If not specified, no trusted proxies will be trusted.\n\n* `ATL_TOMCAT_INTERNALPROXIES`\n\n A list of IP addresses separated by a pipe character e.g. `10.0.9.6|10.0.9.32`. \n Trusted proxies that appear in the `remoteIpHeader` will be trusted and *will not appear*\n in the `proxiesHeader` value. By adding a list of Internal Proxies, Confluence will remove the\n load balancers' IP addresses from Confluence's view of the incoming connection. This could be desired\n in a clustered load balancer architecture where the load balancer address changes depending on\n which node proxies the connection. If not specified, no internal proxies will be trusted.\n\n\n* `ATL_TOMCAT_ADDITIONAL_CONNECTOR_PORT` - If unset, no additional connector is defined in server.xml. No default.\n* `ATL_TOMCAT_ADDITIONAL_CONNECTOR_CONNECTION_TIMEOUT` (default: 20000)\n* `ATL_TOMCAT_ADDITIONAL_CONNECTOR_MAX_THREADS` (default: 50)\n* `ATL_TOMCAT_ADDITIONAL_CONNECTOR_MIN_SPARE_THREADS` (default: 10)\n* `ATL_TOMCAT_ADDITIONAL_CONNECTOR_ENABLE_LOOKUPS` (default: false)\n* `ATL_TOMCAT_ADDITIONAL_CONNECTOR_ACCEPT_COUNT` (default: 10)\n* `ATL_TOMCAT_ADDITIONAL_CONNECTOR_URI_ENCODING` (default: UTF-8)\n* `ATL_TOMCAT_ADDITIONAL_CONNECTOR_SECURE` (no default, if undefined secure is not set in the connector)\n\nThe following Tomcat/Catalina options are also supported. For more information,\nsee . \n\n* `ATL_TOMCAT_MGMT_PORT` (default: 8000)\n* `ATL_TOMCAT_MAXTHREADS` (default: 48)\n* `ATL_TOMCAT_MINSPARETHREADS` (default: 10)\n* `ATL_TOMCAT_CONNECTIONTIMEOUT` (default: 20000)\n* `ATL_TOMCAT_ENABLELOOKUPS` (default: false)\n* `ATL_TOMCAT_PROTOCOL` (default: org.apache.coyote.http11.Http11NioProtocol)\n* `ATL_TOMCAT_REDIRECTPORT` (default: 8443)\n* `ATL_TOMCAT_ACCEPTCOUNT` (default: 10)\n* `ATL_TOMCAT_DEBUG` (default: 0)\n* `ATL_TOMCAT_URIENCODING` (default: UTF-8)\n* `ATL_TOMCAT_MAXHTTPHEADERSIZE` (default: 8192)\n* `ATL_TOMCAT_STUCKTHREADDETECTIONVALVE_THRESHOLD` (default: 60)\n\n### Access Log Settings\n\nYou can set the maximum number of days for access logs to be retained before being deleted. The default value of -1 means never delete old files.\n\n* `ATL_TOMCAT_ACCESS_LOGS_MAXDAYS` (default: -1)\n* `ATL_TOMCAT_ACCESS_LOG_PATTERN` (default: `%h %{X-AUSERNAME}o %t "%r" %s %b %D %U %I "%{User-Agent}i"`)\n\n### JVM configuration\n\nIf you need to pass additional JVM arguments to Confluence such as specifying a\ncustom trust store, you can add them via the below environment variable\n\n* `JVM_SUPPORT_RECOMMENDED_ARGS`\n\n Additional JVM arguments for Confluence.\n\n??? example\n `docker run -e JVM_SUPPORT_RECOMMENDED_ARGS=-Djavax.net.ssl.trustStore=/var/atlassian/application-data/confluence/cacerts -v confluenceVolume:/var/atlassian/application-data/confluence --name=\"confluence\" -d -p 8090:8090 -p 8091:8091 atlassian/confluence`\n\nFor additional settings that can be supplied, see: [Recognized System Properties](https://confluence.atlassian.com/doc/recognized-system-properties-190430.html)\n\n### Confluence-specific settings\n\n* `ATL_AUTOLOGIN_COOKIE_AGE` (default: 1209600; two weeks, in seconds)\n\n The maximum time a user can remain logged-in with 'Remember Me'.\n\n* `CONFLUENCE_HOME`\n\n The confluence home directory. This may be on an mounted volume; if so it\n should be writable by the user `confluence`. See note below about UID\n mappings.\n\n* `ATL_LUCENE_INDEX_DIR`\n\n The directory where [Lucene](https://lucene.apache.org/) search indexes should\n be stored. Defaults to `index` under the Confluence home directory.\n\n* `ATL_LICENSE_KEY` (from Confluence 7.9 onwards)\n\n The Confluence license string. Providing this will remove the need to supply it through the web startup screen.\n\n* **use with caution** `CONFLUENCE_LOG_STDOUT` `[true, false]` (from Confluence 7.9 onwards)\n\n Prior to Confluence version 7.9.0, the log files are always stored in the `logs` folder in Confluence home. From version\n 7.9.0, the logs can be printed directly to the `stdout` and don't use the file at all. This makes it possible to fetch the log messages\n via `docker logs `. In this setup we recommend using some log aggregation tooling (e.g. AWS Cloudwatch or ELK stack).\n\n **Beware, if enabled, the support ZIP produced by the Troubleshooting and Support plugin doesn't contain the application logs.**\n\n* `ATL_SEARCH_PLATFORM`\n \n The search platform to use. Set to `opensearch` if you want to use OpenSearch as the search platform. See: https://confluence.atlassian.com/doc/configuring-opensearch-for-confluence-1387594125.html\n\n* `ATL_OPENSEARCH_HTTP_URL`\n\n HTTP(S) URL of the OpenSearch cluster, or multiple URLs separated by commas.\n\n* `ATL_OPENSEARCH_USERNAME`\n\n Username for the OpenSearch cluster.\n\n* `ATL_OPENSEARCH_PASSWORD`\n\n Password for the OpenSearch cluster.\n\n* `ATL_CONFLUENCE_SESSION_TIMEOUT`\n\n The default Tomcat session timeout (in minutes) for all newly created sessions which is set in web.xml. Defaults to 30.\n\n* `ATL_CONFLUENCE_CFG_ADDITIONAL_PROPERTIES`\n\n Additional properties to be added to `confluence.cfg.xml`. The properties should be in the format `key=value` and separated by a comma. For example, `ATL_CONFLUENCE_CFG_ADDITIONAL_PROPERTIES=confluence.cluster.node.name=node1,confluence.cluster.node.server=server1`.\n\n### Database configuration\n\nIt is optionally possible to configure the database from the environment,\navoiding the need to do so through the web startup screen.\n\nThe following variables are all must all be supplied if using this feature:\n\n* `ATL_JDBC_URL`\n\n The database URL; this is database-specific. It is allowed to use `&` in the URL which will be automatically converted to `&`.\n\n* `ATL_JDBC_USER`\n\n The database user to connect as.\n\n* `ATL_JDBC_PASSWORD`\n\n The password for the database user.\n\n* `ATL_DB_TYPE`\n\n The type of database; valid supported values are:\n\n * `mssql`\n * `mysql`\n * `oracle12c` (Confluence 7.3.0 or earlier only)\n * `oracle` (Confluence 7.3.1 or later only. Compatible with Oracle 12c and Oracle 19c)\n * `postgresql`\n\n???+ note \"MySQL or Oracle JDBC drivers\"\n Due to licensing restrictions Confluence does not ship with a MySQL or Oracle JDBC drivers. \n To use these databases you will need to copy a suitable driver into the container and restart it. \n For example, to copy the MySQL driver into a container named \"confluence\", you would do the following:\n\n `docker cp mysql-connector-java.x.y.z.jar confluence:/opt/atlassian/confluence/confluence/WEB-INF/lib`\n\n `docker restart confluence`\n\nFor more information see the [Database JDBC Drivers](https://confluence.atlassian.com/doc/database-jdbc-drivers-171742.html)\npage.\n\n#### Optional database settings\n\n* `ATL_JDBC_SECRET_CLASS`\n\n[Encryption class](https://confluence.atlassian.com/doc/encrypt-database-password-1115674739.html) for the database password.\nDepending on the secret class, the value of `ATL_JDBC_PASSWORD` will differ. Defaults to plaintext. \n\n!!! warning \"JDBC encryption can only be used with Confluence instances that have already been set up.\"\n\nStarting from 8.6 [AWS SecretsManager](https://confluence.atlassian.com/doc/configuring-confluence-with-aws-secrets-manager-1299911239.html) is supported.\n\nFor non-clustered Confluence, manually edit `jdbc.password.decrypter.classname` and `hibernate.connection.password` properties as instructed by step 5 of official [documentation](https://confluence.atlassian.com/doc/configuring-confluence-with-aws-secrets-manager-1299911239.html), then restart container. \n\nFor clustered Confluence, set this property while making sure environment variables in [cluster configuration](#cluster-configuration) are kept intact as well. \nExample:\n```shell\ndocker run -v /data/your-confluence-home:/var/atlassian/application-data/confluence \\\n--name=\"confluence\" -d -p 8090:8090 -p 8091:8091 \\\n-e ATL_JDBC_SECRET_CLASS='com.atlassian.secrets.store.aws.AwsSecretsManagerStore' \\\n-e ATL_JDBC_PASSWORD='{\"region\": \"us-east-1\", \"secretId\": \"mysecret\", \"secretPointer\": \"/password\"}' \\\n-e ATL_CLUSTER_RELATED_VARIABLES='variable-value' \\\natlassian/confluence\n```\n\nThe following variables are for the database connection pool, and are\noptional.\n\n* `ATL_DB_POOLMINSIZE` (default: 20)\n* `ATL_DB_POOLMAXSIZE` (default: 100)\n* `ATL_DB_TIMEOUT` (default: 30)\n* `ATL_DB_IDLETESTPERIOD` (default: 100)\n* `ATL_DB_MAXSTATEMENTS` (default: 0)\n* `ATL_DB_VALIDATE` (default: false)\n* `ATL_DB_ACQUIREINCREMENT` (default: 1)\n* `ATL_DB_VALIDATIONQUERY` (default: \"select 1\")\n* `ATL_DB_PROVIDER_CLASS` (default: `com.atlassian.confluence.impl.hibernate.DelegatingHikariConnectionProvider`)\n* `ATL_DB_CONNECTION_AUTOCOMMIT` (default false)\n* `ATL_DB_CONNECTION_ISOLATION` (default 2)\n* `ATL_DB_DATASOURCE_HIKARI_REGISTER_MBEANS` (default true)\n\n\n### Data Center configuration\n\nThis docker image can be run as part of a [Data Center][4] cluster. You can\nspecify the following properties to start Confluence as a Data Center node,\ninstead of manually configuring a cluster. See [Installing Confluence Data\nCenter][5] for more information.\n\n#### Cluster configuration\n\nConfluence Data Center allows clustering via various methods. For more\ninformation on the setting for each type see [this page][6].\n\n**NOTE:** The underlying network should be set-up to support the Confluence\nclustering type you are using. How to do this depends on the container\nmanagement technology, and is beyond the scope of this documentation.\n\n##### Common cluster settings\n\n* `ATL_CLUSTER_TYPE`\n\n The cluster type. Setting this effectively enables clustering. Valid values\n are `aws`, `multicast`, and `tcp_ip`.\n\n* `ATL_CLUSTER_NAME`\n\n The cluster name; this should be common across all nodes.\n\n* `ATL_PRODUCT_HOME_SHARED`\n\n The location of the shared home directory for all Confluence nodes. **Note**:\n This must be real shared filesystem that is mounted inside the\n container. Additionally, see the note about UIDs.\n\n* `ATL_CLUSTER_TTL`\n\n The time-to-live for cluster packets. Primarily of use in multicast clusters.\n\n* `ATL_CLUSTER_INTERFACE`\n \n The network interface Confluence will use to communicate between nodes. Auto-detected by default.\n [Override interface](https://confluence.atlassian.com/doc/data-center-troubleshooting-203618.html#DataCenterTroubleshooting-Changemulticastinterface) if Confluence has selected the wrong one.\n \n\n##### AWS cluster settings\n\n The following should be populated from the AWS environment.\n\n* `ATL_HAZELCAST_NETWORK_AWS_IAM_ROLE`\n* `ATL_HAZELCAST_NETWORK_AWS_IAM_REGION`\n* `ATL_HAZELCAST_NETWORK_AWS_HOST_HEADER`\n* `ATL_HAZELCAST_NETWORK_AWS_SECURITY_GROUP`\n* `ATL_HAZELCAST_NETWORK_AWS_TAG_KEY`\n* `ATL_HAZELCAST_NETWORK_AWS_TAG_VALUE`\n\n##### TCP cluster settings\n\n* `ATL_CLUSTER_PEERS`\n\n A comma-separated list of peer IPs.\n\n##### Multicast cluster settings\n\n* `ATL_CLUSTER_ADDRESS`\n\n The multicast address the cluster will communicate on.\n\n### Container Configuration\n\n* `ATL_FORCE_CFG_UPDATE` (default: false)\n\n The Docker [entrypoint][13] generates application configuration on\n first start; not all of these files are regenerated on subsequent\n starts. This is deliberate, to avoid race conditions or overwriting manual\n changes during restarts and upgrades. However in deployments where\n configuration is purely specified through the environment (e.g. Kubernetes)\n this behaviour may be undesirable; this flag forces an update of all\n generated files.\n\n In Confluence the affected files are: `confluence.cfg.xml`\n\n See [the entrypoint code][13] for the details of how configuration\n files are generated.\n\n* `SET_PERMISSIONS` (default: true)\n\n Define whether to set home directory permissions on startup. Set to `false` to disable\n this behaviour.\n\n* `ATL_UNSET_SENSITIVE_ENV_VARS` (default: true)\n\n Define whether to unset environment variables containing keywords 'PASS', 'SECRET' or 'TOKEN'.\n The unset function is executed in the entrypoint. Set to `false` if you want to allow passing\n sensitive environment variables to Confluence container.\n\n???+ warning \"Value exposure on host OS\"\n When using this property, the values to sensitive environment variables will be available in clear text on the \n host OS. As such, this data may be exposed to users or processes running on the host OS.\n\n* `ATL_ALLOWLIST_SENSITIVE_ENV_VARS`\n\n Define a comma separated list of environment variables containing keywords 'PASS', 'SECRET' or 'TOKEN' to be ignored by the unset function which is executed in the entrypoint. The function uses `^` regex. For example, if you set `ATL_ALLOWLIST_SENSITIVE_ENV_VARS=\"PATH_TO_SECRET_FILE\"`, all variables starting with `PATH_TO_SECRET_FILE` will not be unset.\n\n???+ warning \"Value exposure on host OS\"\n When using this property, the values to sensitive environment variables will be available in clear text on the \n host OS. As such, this data may be exposed to users or processes running on the host OS.\n\n### Advanced Configuration\n\nAs mentioned at the top of this section, the settings from the environment are\nused to populate the application configuration on the container startup. However,\nin some cases you may wish to customise the settings in ways that are not\nsupported by the environment variables above. In this case, it is possible to\nmodify the base templates to add your own configuration. There are three main\nways of doing this; modify our repository to your own image, build a new image\nfrom the existing one, or provide new templates at startup. We will briefly\noutline these methods here, but in practice how you do this will depend on your\nneeds.\n\n##### Building your own image\n\n* Clone the Atlassian repository at \n* Modify or replace the [Jinja](https://jinja.palletsprojects.com/) templates\n under `config`; _NOTE_: The files must have the `.j2` extensions. However you\n don't have to use template variables if you don't wish.\n* Build the new image with e.g: `docker build --tag my-confluence-image --build-arg CONFLUENCE_VERSION=6.x.x .`\n* Optionally push to a registry, and deploy.\n\n##### Build a new image from the existing one\n\n* Create a new `Dockerfile`, which starts with the line e.g: `FROM atlassian/confluence:latest`.\n* Use a `COPY` line to overwrite the provided templates.\n* Build, push and deploy the new image as above.\n\n##### Overwrite the templates at runtime\n\nThere are two main ways of doing this:\n\n* If your container is going to be long-lived, you can create it, modify the\n installed templates under `/opt/atlassian/etc/`, and then run it.\n* Alternatively, you can create a volume containing your alternative templates,\n and mount it over the provided templates at runtime\n with `--volume my-config:/opt/atlassian/etc/`.\n\n## Shared directory and user IDs\n\nBy default the Confuence application runs as the user `confluence`, with a UID\nand GID of 2002. Consequently this UID must have write access to the shared\nfilesystem. If for some reason a different UID must be used, there are a number\nof options available:\n\n* The Docker image can be rebuilt with a different UID.\n* Under Linux, the UID can be remapped using\n [user namespace remapping][7].\n\nTo preserve strict permissions for certain configuration files, this container starts as\n`root` to perform bootstrapping before running Confluence under a non-privileged user\naccount. If you wish to start the container as a non-root user, please note that Tomcat\nconfiguration, and the bootstrapping of seraph-config.xml (SSO) &\nconfluence-init.properties (overriding `$CONFLUENCE_HOME`) will be skipped and a warning\nwill be logged. You may still apply custom configuration in this situation by mounting a\ncustom file directly, e.g. by mounting your own server.xml file directly to\n`/opt/atlassian/confluence/conf/server.xml`\n\nDatabase and Clustering bootstrapping will work as expected when starting this container\nas a non-root user.\n\n## Upgrade\n\nTo upgrade to a more recent version of Confluence Server you can simply stop the\n`Confluence` container and start a new one based on a more recent image:\n```shell\ndocker stop confluence\ndocker rm confluence\ndocker run ... (see above)\n```\nAs your data is stored in the data volume directory on the host, it will still\nbe available after the upgrade.\n\n!!! note \"Please make sure that you **don't** accidentally remove the `confluence` container and its volumes using the `-v` option.\"\n\n## Backup\n\nFor evaluating Confluence you can use the built-in database that will store its\nfiles in the Confluence Server home directory. In that case it is sufficient to\ncreate a backup archive of the directory on the host that is used as a volume\n(`/data/your-confluence-home` in the example above).\n\nConfluence's [automatic backup][8] is currently supported in the Docker\nsetup. You can also use the [Production Backup Strategy][9] approach if you're\nusing an external database.\n\nRead more about data recovery and backups: [Site Backup and Restore][10]\n\n## Shutdown\n\nConfluence allows a grace period of 20s for active operations to finish before\ntermination. If sending a `docker stop` this should be taken into account with\nthe `--time` flag.\n\nAlternatively, the script `/shutdown-wait.sh` is provided, which will initiate a\nclean shutdown and wait for the process to complete. This is the recommended\nmethod for shutdown in environments which provide for orderly shutdown,\ne.g. Kubernetes via the `preStop` hook.\n\n## Versioning\n\nThe `latest` tag matches the most recent official release of Atlassian Confluence Server.\nSo `atlassian/confluence:latest` will use the newest stable version of\nConfluence Server available.\n\nAlternatively, you can use a specific minor version of Confluence Server by\nusing a version number tag: `atlassian/confluence:7.13`. This will\ninstall the latest `7.13.x` version that is available.\n\nWe also publish docker images for our [EAP releases](https://www.atlassian.com/software/confluence/download-eap) (not\nsupported for use in production). The tag for EAP releases is the EAP version.\nFor example to get the `7.8.0-beta1` EAP release, use `atlassian/confluence:7.8.0-beta1`.\n\nFor example, `atlassian/confluence:7.13-ubuntu-jdk11` will\ninstall the latest 7.13.x version with Eclipse Temurin OpenJDK 11.\n\n## Supported JDK versions and base images\n\nAtlassian Docker images are generated from the\n[official Eclipse Temurin OpenJDK Docker images](https://hub.docker.com/_/eclipse-temurin).\n\nStarting from 8.5.6 [UBI based](https://catalog.redhat.com/software/containers/ubi9/openjdk-17/61ee7c26ed74b2ffb22b07f6?architecture=amd64) tags are published as well.\nTags are available in 2 formats: `-ubi9` and `-ubi9-jdk17`.\n\nThe build pipeline pushes both JDK11 and JDK17 tags for Confluence versions ranging from 7.19 to 8.9.\nStarting from 9.0 only JDK17 tags are published. UBI based tags are JDK17 only.\n\nThe Docker images follow the [Atlassian Support end-of-life\npolicy](https://confluence.atlassian.com/support/atlassian-support-end-of-life-policy-201851003.html);\nimages for unsupported versions of the products remain available but will no longer\nreceive updates or fixes.\n\nHistorically, we have also generated other versions of the images, including\nJDK8, Alpine, and 'slim' versions of the JDK. These legacy images still exist in\nDocker Hub, however they should be considered deprecated, and do not receive\nupdates or fixes.\n\nIf for some reason you need a different version, see \"Building your own image\"\nabove.\n\n## Migration to UBI\n\nIf you have been mounting any files to `${JAVA_HOME}` directory in `eclipse-temurin` based container, `JAVA_HOME` in UBI JDK17 container is set to `/usr/lib/jvm/java-17`.\n\nAlso, if you have been mounting and running any custom scripts in the container, UBI-based images may lack some tools and utilities that are available out of the box in eclipse-temurin tags. If that's the case, see [Building your own image](#building-your-own-image).\n\n\n## Supported architectures\n\nCurrently, Confluence container images are built for the `linux/amd64` and `linux/arm64` target platforms.\nThe Dockerfiles and support tooling have now had all\narchitecture-specific components removed, so if necessary it is possible to\nbuild images for any platform supported by OCI-compliant container runtimes.\n\n### Building on the target architecture\n\nNote: This method is known to work on Mac M1 and AWS ARM64 machines, but has not\nbeen extensively tested.\n\nThe simplest method of getting a platform image is to build it on a target\nmachine. The following assumes you have git and Docker installed. You will also\nneed to know which version of Confluence you want to build; substitute\n`CONFLUENCE_VERSION=x.x.x` with your required version:\n\n```shell\ngit clone --recurse-submodule https://bitbucket.org/atlassian-docker/docker-atlassian-confluence-server.git\ncd docker-atlassian-confluence-server\ndocker build --tag my-image --build-arg CONFLUENCE_VERSION=x.x.x .\n```\nThis image can be pushed up to your own Docker Hub or private repository.\n\n## Troubleshooting\n\nThese images include built-in scripts to assist in performing common JVM diagnostic tasks.\n\n### Thread dumps\n\n`/opt/atlassian/support/thread-dumps.sh` can be run via `docker exec` to easily trigger the collection of thread\ndumps from the containerized application. For example:\n\n```shell\ndocker exec my_container /opt/atlassian/support/thread-dumps.sh\n```\n\nBy default, this script will collect 10 thread dumps at 5 second intervals. This can\nbe overridden by passing a custom value for the count and interval, by using `-c` / `--count`\nand `-i` / `--interval` respectively. For example, to collect 20 thread dumps at 3 second intervals:\n\n```shell\ndocker exec my_container /opt/atlassian/support/thread-dumps.sh --count 20 --interval 3\n```\n\nThread dumps will be written to `$APP_HOME/thread_dumps/`.\n\n???+ note \"Disable capturing output from top run\"\n By default this script will also capture output from top run in 'Thread-mode'. This can\n be disabled by passing `-n` / `--no-top`\n\n### Heap dump\n\n`/opt/atlassian/support/heap-dump.sh` can be run via `docker exec` to easily trigger the collection of a heap\ndump from the containerized application. For example:\n\n```shell\ndocker exec my_container /opt/atlassian/support/heap-dump.sh\n```\n\nA heap dump will be written to `$APP_HOME/heap.bin`. If a file already exists at this\nlocation, use `-f` / `--force` to overwrite the existing heap dump file.\n\n### Manual diagnostics\n\nThe `jcmd` utility is also included in these images and can be used by starting a `bash` shell\nin the running container:\n\n```shell\ndocker exec -it my_container /bin/bash\n```\n\n## Support\n\nFor product support, go to\n[support.atlassian.com](https://support.atlassian.com/confluence-server/).\n\nYou can also visit the [Atlassian Data Center](https://community.atlassian.com/t5/Atlassian-Data-Center-on/gh-p/DC_Kubernetes)\nforum for discussion on running Atlassian Data Center products in containers.\n\n## Contribution\n\nSee the [contributing guideline][14] if you are contributing from outside Atlassian.\n\n## Changelog\n\nFor a detailed list of changes to the Docker image configuration see [the Git\ncommit history](https://bitbucket.org/atlassian-docker/docker-atlassian-confluence-server/commits/).\n\n## License\n\nCopyright © 2020 Atlassian Corporation Pty Ltd.\nLicensed under the Apache License, Version 2.0.\n\n[1]: https://docs.docker.com/userguide/dockervolumes/#mount-a-host-directory-as-a-data-volume\n[3]: https://confluence.atlassian.com/display/DOC/Supported+platforms\n[4]: https://confluence.atlassian.com/doc/confluence-data-center-technical-overview-790795847.html\n[5]: https://confluence.atlassian.com/doc/installing-confluence-data-center-203603.html\n[6]: https://confluence.atlassian.com/doc/change-node-discovery-from-multicast-to-tcp-ip-or-aws-792297728.html#ChangeNodeDiscoveryfromMulticasttoTCP/IPorAWS-TochangefromTCP/IPtomulticast\n[7]: https://docs.docker.com/engine/security/userns-remap/\n[8]: https://confluence.atlassian.com/display/DOC/Configuring+Backups\n[9]: https://confluence.atlassian.com/display/DOC/Production+Backup+Strategy\n[10]: https://confluence.atlassian.com/display/DOC/Site+Backup+and+Restore\n[12]: https://confluence.atlassian.com/doc/confluence-6-13-release-notes-959288785.html\n[13]: https://bitbucket.org/atlassian-docker/docker-atlassian-confluence-server/src/master/entrypoint.py\n[14]: https://bitbucket.org/atlassian-docker/docker-atlassian-confluence-server/src/master/CONTRIBUTING.md\n" }, { "path": "docs/docs/containers/CROWD.md", "content": "# ![Atlassian Crowd](https://wac-cdn.atlassian.com/dam/jcr:d2a1da52-ae52-4b06-9ab1-da8647a89653/crowd-icon-gradient-blue.svg?cdnVersion=696){: style=\"height:35px;width:35px\"} Crowd\n\n## Overview\n\nCrowd provides single sign-on and user identity that's easy to use.\n\nLearn more about Crowd: [https://www.atlassian.com/software/crowd][1]\n\nThis Docker container makes it easy to get an instance of Crowd up and running.\n\n**Use docker version >= 20.10.10**\n\n## Quick Start\n\nFor the `CROWD_HOME` directory that is used to store application data (amongst other things) we recommend mounting a host directory as a [data volume](https://docs.docker.com/engine/tutorials/dockervolumes/#/data-volumes), or via a named volume.\n\nTo get started you can use a data volume, or named volumes. In this example we'll use named volumes.\n```shell\ndocker volume create --name crowdVolume\ndocker run -v crowdVolume:/var/atlassian/application-data/crowd --name=\"crowd\" -d -p 8095:8095 atlassian/crowd\n```\n!!! success \"Crowd is now available on [http://localhost:8095](http://localhost:8095).\"\n\nPlease ensure your container has the necessary resources allocated to it. See [Supported Platforms][2] for further information.\n\n???+ tip \"If you are using `docker-machine` on Mac OS X, please use `open http://$(docker-machine ip default):8095` instead.\"\n\n## Common settings\n\n### Verbose container entrypoint logging\n\nDuring the startup process of the container, various operations and checks are performed to ensure that the application\nis configured correctly and ready to run. To help in troubleshooting and to provide transparency into this process, you\ncan enable verbose logging. The `VERBOSE_LOGS` environment variable enables detailed debug messages to the container's\nlog, offering insights into the actions performed by the entrypoint script.\n\n* `VERBOSE_LOGS` (default: false)\n\n Set to `true` to enable detailed debug messages during the container initialization.\n\n### Memory / Heap Size\n\nIf you need to override Crowd's default memory allocation, you can control the minimum heap (Xms) and maximum heap (Xmx) via the below environment variables.\n\n* `JVM_MINIMUM_MEMORY` (default: 384m)\n\n The minimum heap size of the JVM\n\n* `JVM_MAXIMUM_MEMORY` (default: 768m)\n\n The maximum heap size of the JVM\n\n### Reverse Proxy Settings\n\nIf Crowd is run behind a reverse proxy server as [described here][3], then you need to specify extra options to make Crowd aware of the setup. They can be controlled via the below environment variables.\n\n* `ATL_TOMCAT_CONTEXTPATH` (default: /crowd)\n\n The context path the application is served over.\n\n* `ATL_PROXY_NAME` (default: NONE)\n\n The reverse proxy's fully qualified hostname. `CATALINA_CONNECTOR_PROXYNAME`\n is also supported for backwards compatability.\n\n* `ATL_PROXY_PORT` (default: NONE)\n\n The reverse proxy's port number via which Crowd is\n accessed. `CATALINA_CONNECTOR_PROXYPORT` is also supported for backwards\n compatability.\n\n* `ATL_TOMCAT_PORT` (default: 8095)\n\n The port for Tomcat/Crowd to listen on. Depending on your container\n deployment method this port may need to be\n [exposed and published][docker-expose].\n\n* `ATL_TOMCAT_SCHEME` (default: http)\n\n The protocol via which Crowd is accessed. `CATALINA_CONNECTOR_SCHEME` is also\n supported for backwards compatability.\n\n* `ATL_TOMCAT_SECURE` (default: false)\n\n Set 'true' if `ATL_TOMCAT_SCHEME` is 'https'. `CATALINA_CONNECTOR_SECURE` is\n also supported for backwards compatability.\n\nThe following Tomcat/Catalina options are also supported. For more information,\nsee https://tomcat.apache.org/tomcat-8.5-doc/config/index.html.\n\n* `ATL_TOMCAT_MGMT_PORT` (default: 8000)\n* `ATL_TOMCAT_MAXTHREADS` (default: 100)\n* `ATL_TOMCAT_MINSPARETHREADS` (default: 10)\n* `ATL_TOMCAT_CONNECTIONTIMEOUT` (default: 20000)\n* `ATL_TOMCAT_ENABLELOOKUPS` (default: false)\n* `ATL_TOMCAT_PROTOCOL` (default: HTTP/1.1)\n* `ATL_TOMCAT_ACCEPTCOUNT` (default: 10)\n* `ATL_TOMCAT_MAXHTTPHEADERSIZE` (default: 8192)\n\n### Access Log Settings\n\nYou can set the maximum number of days for access logs to be retained before being deleted. The default value of -1 means never delete old files.\n\n* `ATL_TOMCAT_ACCESS_LOGS_MAXDAYS` (default: -1)\n\n### JVM Configuration\n\nIf you need to pass additional JVM arguments to Crowd, such as specifying a custom trust store, you can add them via the below environment variable\n\n* `JVM_SUPPORT_RECOMMENDED_ARGS`\n\n Additional JVM arguments for Crowd\n\n??? example \n `docker run -e JVM_SUPPORT_RECOMMENDED_ARGS=-Djavax.net.ssl.trustStore=/var/atlassian/application-data/crowd/cacerts -v crowdVolume:/var/atlassian/application-data/crowd --name=\"crowd\" -d -p 8095:8095 atlassian/crowd` \n\n### Data Center configuration\n\nThis docker image can be run as part of a [Data Center][4] cluster. You can\nspecify the following properties to start Crowd as a Data Center node,\ninstead of manually configuring a cluster. See [Installing Crowd Data\nCenter][5] for more information.\n\n### Container Configuration\n\n* `SET_PERMISSIONS` (default: true)\n\n Define whether to set home directory permissions on startup. Set to `false` to disable\n this behaviour.\n\n### Advanced Configuration\n\nAs mentioned at the top of this section, the settings from the environment are\nused to populate the application configuration on the container startup. However,\nin some cases you may wish to customise the settings in ways that are not\nsupported by the environment variables above. In this case, it is possible to\nmodify the base templates to add your own configuration. There are three main\nways of doing this; modify our repository to your own image, build a new image\nfrom the existing one, or provide new templates at startup. We will briefly\noutline these methods here, but in practice how you do this will depend on your\nneeds.\n\n##### Building your own image\n\n* Clone the Atlassian repository at https://bitbucket.org/atlassian-docker/docker-atlassian-crowd/\n* Modify or replace the [Jinja](https://jinja.palletsprojects.com/) templates\n under `config`; _NOTE_: The files must have the `.j2` extensions. However you\n don't have to use template variables if you don't wish.\n* Build the new image with e.g: `docker build --tag my-crowd-image --build-arg CROWD_VERSION=3.x.x .`\n* Optionally push to a registry, and deploy.\n\n##### Build a new image from the existing one\n\n* Create a new `Dockerfile`, which starts with the Atlassian Crowd base image e.g: `FROM atlassian/crowd:latest`.\n* Use a `COPY` line to overwrite the provided templates.\n* Build, push and deploy the new image as above.\n\n##### Overwrite the templates at runtime\n\nThere are two main ways of doing this:\n\n* If your container is going to be long-lived, you can create it, modify the\n installed templates under `/opt/atlassian/etc/`, and then run it.\n* Alternatively, you can create a volume containing your alternative templates,\n and mount it over the provided templates at runtime\n with `--volume my-config:/opt/atlassian/etc/`.\n\n## Shared directory and user IDs\n\nBy default the Crowd application runs as the user `crowd`, with a UID\nand GID of 2004. Consequently this UID must have write access to the shared\nfilesystem. If for some reason a different UID must be used, there are a number\nof options available:\n\n* The Docker image can be rebuilt with a different UID.\n* Under Linux, the UID can be remapped using\n [user namespace remapping][7].\n\nTo preserve strict permissions for certain configuration files, this container starts as\n`root` to perform bootstrapping before running Crowd under a non-privileged user\naccount. If you wish to start the container as a non-root user, please note that Tomcat\nconfiguration will be skipped and a warning will be logged. You may still apply custom\nconfiguration in this situation by mounting configuration files directly, e.g.\nby mounting your own server.xml file directly to\n`/opt/atlassian/crowd/apache-tomcat/conf/server.xml`\n\n## Upgrade\n\nTo upgrade to a more recent version of Crowd you can simply stop the `crowd` container and start a new one based on a more recent image:\n\n```shell\ndocker stop crowd\ndocker rm crowd\ndocker run ... (See above)\n```\n\nAs your data is stored in the data volume directory on the host it will still be available after the upgrade.\n\n!!! note \"Please make sure that you **don't** accidentally remove the `crowd` container and its volumes using the `-v` option.\"\n\n## Backup\n\nFor evaluations you can use the built-in database that will store its files in the Crowd home directory. In that case it is sufficient to create a backup archive of the docker volume.\n\nIf you're using an external database, you can configure Crowd to make a backup automatically each night. This will back up the current state, including the database to the `crowdVolume` docker volume, which can then be archived. Alternatively you can backup the database separately, and continue to create a backup archive of the docker volume to back up the Crowd Home directory.\n\nRead more about data recovery and backups: [Backing Up and Restoring Data][6]\n\n## Versioning\n\nThe `latest` tag matches the most recent release of Atlassian Crowd. Thus `atlassian/crowd:latest` will use the newest version of Crowd available.\n\nAlternatively you can use a specific major, major.minor, or major.minor.patch version of Crowd by using a version number tag:\n\n* `atlassian/crowd:3`\n* `atlassian/crowd:3.2`\n* `atlassian/crowd:3.2.3`\n\nAll versions from 3.0+ are available\n\n## Supported JDK versions and base images\n\nAll Atlassian Crowd Docker images are now JDK11 only, and generated from the\n[official Eclipse Temurin OpenJDK Docker images](https://hub.docker.com/_/eclipse-temurin).\n\nStarting from 5.2.3 [UBI based](https://catalog.redhat.com/software/containers/ubi9/openjdk-11-runtime/61ee7d1c33f211c45407a91c) tags are published as well.\nUBI tags are available in 2 formats: `-ubi9` and `-ubi9-jdk11`.\n\nThe Docker images follow the [Atlassian Support end-of-life\npolicy](https://confluence.atlassian.com/support/atlassian-support-end-of-life-policy-201851003.html);\nimages for unsupported versions of the products remain available but will no longer\nreceive updates or fixes.\n\nHistorically, we have also generated other versions of the images, including\nJDK8, Alpine, and 'slim' versions of the JDK. These legacy images still exist in\nDocker Hub, however they should be considered deprecated, and do not receive\nupdates or fixes.\n\nIf for some reason you need a different version, see \"Building your own image\"\nabove.\n\n## Migration to UBI\n\nIf you have been mounting any files to `${JAVA_HOME}` directory in `eclipse-temurin` based container, `JAVA_HOME` in UBI JDK11 container is set to `/usr/lib/jvm/java-11`.\n\nAlso, if you have been mounting and running any custom scripts in the container, UBI-based images may lack some tools and utilities that are available out of the box in `eclipse-temurin` tags. If that's the case, see [Building your own image](#building-your-own-image).\n\n\n## Supported architectures\n\nCurrently, Crowd container images are built for the `linux/amd64` and `linux/arm64` target platforms.\nThe Dockerfiles and support tooling have now had all\narchitecture-specific components removed, so if necessary it is possible to\nbuild images for any platform supported by OCI-compliant container runtimes.\n\n### Building on the target architecture\n\nNote: This method is known to work on Mac M1 and AWS ARM64 machines, but has not\nbeen extensively tested.\n\nThe simplest method of getting a platform image is to build it on a target\nmachine. The following assumes you have git and Docker installed. You will also\nneed to know which version of Crowd you want to build; substitute\n`CROWD_VERSION=x.x.x` with your required version:\n\n```shell\ngit clone --recurse-submodule https://bitbucket.org/atlassian-docker/docker-atlassian-crowd.git\ncd docker-atlassian-crowd\ndocker build --tag my-image --build-arg CROWD_VERSION=x.x.x .\n```\nThis image can be pushed up to your own Docker Hub or private repository.\n\n## Troubleshooting\n\nThese images include built-in scripts to assist in performing common JVM diagnostic tasks.\n\n### Thread dumps\n\n`/opt/atlassian/support/thread-dumps.sh` can be run via `docker exec` to easily trigger the collection of thread\ndumps from the containerized application. For example:\n\n```shell\ndocker exec my_crowd /opt/atlassian/support/thread-dumps.sh\n```\n\nBy default this script will collect 10 thread dumps at 5 second intervals. This can\nbe overridden by passing a custom value for the count and interval, by using `-c` / `--count`\nand `-i` / `--interval` respectively. For example, to collect 20 thread dumps at 3 second intervals:\n\n```shell\ndocker exec my_container /opt/atlassian/support/thread-dumps.sh --count 20 --interval 3\n```\n\nThread dumps will be written to `$APP_HOME/thread_dumps/`.\n\n???+ note \"Disable capturing output from top run\"\n By default this script will also capture output from top run in 'Thread-mode'. This can\n be disabled by passing `-n` / `--no-top`\n\n### Heap dump\n\n`/opt/atlassian/support/heap-dump.sh` can be run via `docker exec` to easily trigger the collection of a heap\ndump from the containerized application. For example:\n\n```shell\ndocker exec my_container /opt/atlassian/support/heap-dump.sh\n```\n\nA heap dump will be written to `$APP_HOME/heap.bin`. If a file already exists at this\nlocation, use `-f` / `--force` to overwrite the existing heap dump file.\n\n### Manual diagnostics\n\nThe `jcmd` utility is also included in these images and can be used by starting a `bash` shell\nin the running container:\n\n```shell\ndocker exec -it my_container /bin/bash\n```\n\n## Support\n\nFor product support, go to:\n\n* https://support.atlassian.com/crowd/\n\nYou can also visit the [Atlassian Data Center](https://community.atlassian.com/t5/Atlassian-Data-Center-on/gh-p/DC_Kubernetes)\nforum for discussion on running Atlassian Data Center products in containers.\n\n## Changelog\n\nFor a detailed list of changes to the Docker image configuration see [the Git\ncommit history](https://bitbucket.org/atlassian-docker/docker-atlassian-crowd/commits/).\n\n## License\n\nCopyright © 2019 Atlassian Corporation Pty Ltd.\nLicensed under the Apache License, Version 2.0.\n\n[1]: https://www.atlassian.com/software/crowd\n[2]: https://confluence.atlassian.com/crowd/supported-platforms-191851.html\n[3]: https://confluence.atlassian.com/crowd031/integrating-crowd-with-apache-949753124.html\n[4]: https://confluence.atlassian.com/crowd/crowd-data-center-935372453.html\n[5]: https://confluence.atlassian.com/crowd/installing-crowd-data-center-935369773.html\n[6]: https://confluence.atlassian.com/crowd/backing-up-and-restoring-data-36470797.html\n[7]: https://docs.docker.com/engine/security/userns-remap/\n" }, { "path": "docs/docs/containers/JIRA.md", "content": "# ![Atlassian Jira Software](https://wac-cdn.atlassian.com/dam/jcr:826c97dc-1f5c-4955-bfcc-ea17d6b0c095/jira%20software-icon-gradient-blue.svg?cdnVersion=492){: style=\"height:35px;width:35px\"}![Atlassian Jira Service Management](https://wac-cdn.atlassian.com/dam/jcr:8e0905be-0ee7-4652-ba3a-4e3db1143969/jira%20service%20desk-icon-gradient-blue.svg?cdnVersion=492){: style=\"height:35px;width:35px\"}![Atlassian Jira Core](https://wac-cdn.atlassian.com/dam/jcr:f89f1ce5-60f1-47c2-b9f5-657de4940d31/jira%20core-icon-gradient-blue.svg?cdnVersion=492){: style=\"height:35px;width:35px\"} Jira\n\n## Overview\n\nJira Software Data Center helps the world’s best agile teams plan, track, and release great software at scale.\n\n* Check out [atlassian/jira-software](http://hub.docker.com/r/atlassian/jira-software/) on Docker Hub\n* Learn more about Jira Software: [https://www.atlassian.com/software/jira](https://www.atlassian.com/software/jira)\n\nJira Service Management Data Center is an enterprise ITSM solution that offers high availability, meeting your security and compliance needs so no request goes unresolved.\n\n* Check out [atlassian/jira-servicemanagement](http://hub.docker.com/r/atlassian/jira-servicemanagement/) on Docker Hub\n* Learn more about Jira Service Management: [https://www.atlassian.com/software/jira/service-management](https://www.atlassian.com/software/jira/service-management)\n\nJira Core is a project and task management solution built for business teams.\n\n* Check out [atlassian/jira-core](http://hub.docker.com/r/atlassian/jira-core/) on Docker Hub\n* Learn more about Jira Core: [https://www.atlassian.com/software/jira/core](https://www.atlassian.com/software/jira/core)\n\nThis Docker container makes it easy to get an instance of Jira Software, Service Management or Core up and running.\n\nNote: Jira Software will be referenced in the examples provided.\n\n**Use docker version >= 20.10.10**\n\n## Quick Start\n\nFor the `JIRA_HOME` directory that is used to store application data (amongst\nother things) we recommend mounting a host directory as a [data\nvolume](https://docs.docker.com/engine/tutorials/dockervolumes/#/data-volumes),\nor via a named volume.\n\nAdditionally, if running Jira in Data Center mode it is required that a shared\nfilesystem is mounted. The mount point (inside the container) can be configured\nwith `JIRA_SHARED_HOME`.\n\nTo get started you can use a data volume, or named volumes. In this example\nwe'll use named volumes.\n\n```shell\ndocker volume create --name jiraVolume\ndocker run -v jiraVolume:/var/atlassian/application-data/jira --name=\"jira\" -d -p 8080:8080 atlassian/jira-software\n```\n\n!!! success \"Jira is now available on [http://localhost:8080](http://localhost:8080).\"\n\nPlease ensure your container has the necessary resources allocated to it. We\nrecommend 2GiB of memory allocated to accommodate the application server. See\n[System Requirements](https://confluence.atlassian.com/adminjiraserver071/jira-applications-installation-requirements-802592164.html)\nfor further information.\n\n???+ tip \"If you are using `docker-machine` on Mac OS X, please use `open http://$(docker-machine ip default):8080` instead.\"\n\n## Configuring Jira\n\nThis Docker image is intended to be configured from its environment; the\nprovided information is used to generate the application configuration files\nfrom templates. This allows containers to be repeatably created and destroyed\non-the-fly, as required in advanced cluster configurations. Most aspects of the\ndeployment can be configured in this manner; the necessary environment variables\nare documented below. However, if your particular deployment scenario is not\ncovered by these settings, it is possible to override the provided templates\nwith your own; see the section [Advanced Configuration](#advanced-configuration) below.\n\n### Verbose container entrypoint logging\n\nDuring the startup process of the container, various operations and checks are performed to ensure that the application\nis configured correctly and ready to run. To help in troubleshooting and to provide transparency into this process, you\ncan enable verbose logging. The `VERBOSE_LOGS` environment variable enables detailed debug messages to the container's\nlog, offering insights into the actions performed by the entrypoint script.\n\n* `VERBOSE_LOGS` (default: false)\n\n Set to `true` to enable detailed debug messages during the container initialization.\n\n### Memory / Heap Size\n\nIf you need to override Jira's default memory allocation, you can control the minimum heap (Xms) and maximum heap (Xmx) via the below environment variables.\n\n* `JVM_MINIMUM_MEMORY` (default: 384m)\n\n The minimum heap size of the JVM\n\n* `JVM_MAXIMUM_MEMORY` (default: 768m)\n\n The maximum heap size of the JVM\n\n* `JVM_RESERVED_CODE_CACHE_SIZE` (default: 512m)\n\n The reserved code cache size of the JVM\n\n### Reverse Proxy Settings\n\nIf Jira is run behind a reverse proxy server (e.g. a load-balancer or nginx server) as\n[described here](https://confluence.atlassian.com/adminjiraserver072/integrating-jira-with-apache-using-ssl-828788158.html),\nthen you need to specify extra options to make Jira aware of the setup. They can\nbe controlled via the below environment variables.\n\n* `ATL_PROXY_NAME` (default: NONE)\n\n The reverse proxy's fully qualified hostname. `CATALINA_CONNECTOR_PROXYNAME`\n is also supported for backwards compatability.\n\n* `ATL_PROXY_PORT` (default: NONE)\n\n The reverse proxy's port number via which Jira is\n accessed. `CATALINA_CONNECTOR_PROXYPORT` is also supported for backwards\n compatability.\n\n* `ATL_TOMCAT_PORT` (default: 8080)\n\n The port for Tomcat/Jira to listen on. Depending on your container\n deployment method this port may need to be\n [exposed and published][docker-expose].\n\n* `ATL_TOMCAT_SCHEME` (default: http)\n\n The protocol via which Jira is accessed. `CATALINA_CONNECTOR_SCHEME` is also\n supported for backwards compatability.\n\n* `ATL_TOMCAT_SECURE` (default: false)\n\n Set 'true' if `ATL_TOMCAT_SCHEME` is 'https'. `CATALINA_CONNECTOR_SECURE` is\n also supported for backwards compatability.\n\n* `ATL_TOMCAT_CONTEXTPATH` (default: NONE)\n\n The context path the application is served over. `CATALINA_CONTEXT_PATH` is\n also supported for backwards compatability.\n\n* `ATL_TOMCAT_REQUESTATTRIBUTESENABLED`\n\n Checks for the existence of request attributes (typically set by the RemoteIpValve and similar)\n that should be used to override the values returned by the request for remote address,\n remote host, server port and protocol. This property is usually combined with `ATL_TOMCAT_TRUSTEDPROXIES`\n and `ATL_TOMCAT_INTERNALPROXIES` to show IP address of the remote host instead of the load balancer's.\n If not declared, the default value of `false` will be used.\n\n* `ATL_TOMCAT_TRUSTEDPROXIES`\n\n A list of IP addresses separated by a pipe character e.g. `10.0.9.6|10.0.9.32`. \n Trusted proxies that appear in the `remoteIpHeader` will be trusted and *will appear*\n in the `proxiesHeader` value. By adding a list of Trusted Proxies, Confluence will remove the\n load balancers' IP addresses from Confluence's view of the incoming connection. This could be desired\n in a clustered load balancer architecture where the load balancer address changes depending on\n which node proxies the connection.\n If not specified, no trusted proxies will be trusted.\n\n* `ATL_TOMCAT_INTERNALPROXIES`\n\n A list of IP addresses separated by a pipe character e.g. `10.0.9.6|10.0.9.32`. \n Trusted proxies that appear in the `remoteIpHeader` will be trusted and *will not appear*\n in the `proxiesHeader` value. By adding a list of Internal Proxies, Confluence will remove the\n load balancers' IP addresses from Confluence's view of the incoming connection. This could be desired\n in a clustered load balancer architecture where the load balancer address changes depending on\n which node proxies the connection.\n If not specified, no internal proxies will be trusted.\n\n* `ATL_TOMCAT_ADDITIONAL_CONNECTOR_PORT` - If unset, no additional connector is defined in server.xml. No default.\n* `ATL_TOMCAT_ADDITIONAL_CONNECTOR_CONNECTION_TIMEOUT` (default: 20000)\n* `ATL_TOMCAT_ADDITIONAL_CONNECTOR_MAX_THREADS` (default: 50)\n* `ATL_TOMCAT_ADDITIONAL_CONNECTOR_MIN_SPARE_THREADS` (default: 10)\n* `ATL_TOMCAT_ADDITIONAL_CONNECTOR_ENABLE_LOOKUPS` (default: false)\n* `ATL_TOMCAT_ADDITIONAL_CONNECTOR_ACCEPT_COUNT` (default: 10)\n* `ATL_TOMCAT_ADDITIONAL_CONNECTOR_URI_ENCODING` (default: UTF-8)\n* `ATL_TOMCAT_ADDITIONAL_CONNECTOR_SECURE` (no default, if undefined secure is not set in the connector)\n\nThe following Tomcat/Catalina options are also supported. For more information,\nsee https://tomcat.apache.org/tomcat-7.0-doc/config/index.html.\n\n* `ATL_TOMCAT_MGMT_PORT` (default: 8005)\n* `ATL_TOMCAT_MAXTHREADS` (default: 100)\n* `ATL_TOMCAT_MINSPARETHREADS` (default: 10)\n* `ATL_TOMCAT_CONNECTIONTIMEOUT` (default: 20000)\n* `ATL_TOMCAT_ENABLELOOKUPS` (default: false)\n* `ATL_TOMCAT_PROTOCOL` (default: HTTP/1.1)\n* `ATL_TOMCAT_ACCEPTCOUNT` (default: 10)\n* `ATL_TOMCAT_MAXHTTPHEADERSIZE` (default: 8192)\n* `ATL_TOMCAT_STUCKTHREADDETECTIONVALVE_THRESHOLD` (default: 120)\n\n### Access Log Settings\n\nYou can set the maximum number of days for access logs to be retained before being deleted. The default value of -1 means never delete old files.\n\n* `ATL_TOMCAT_ACCESS_LOGS_MAXDAYS` (default: -1)\n* `ATL_TOMCAT_ACCESS_LOG_PATTERN` (default: `%a %{jira.request.id}r %{jira.request.username}r %t "%m %U%q %H" %s %b %D "%{Referer}i" "%{User-Agent}i" "%{jira.request.assession.id}r"`)\n\n### JVM configuration\n\nIf you need to pass additional JVM arguments to Jira, such as specifying a custom trust store, you can add them via the below environment variable\n\n* `JVM_SUPPORT_RECOMMENDED_ARGS`\n\n Additional JVM arguments for Jira\n\n??? example \n `docker run -e JVM_SUPPORT_RECOMMENDED_ARGS=-Djavax.net.ssl.trustStore=/var/atlassian/application-data/jira/cacerts -v jiraVolume:/var/atlassian/application-data/jira --name=\"jira\" -d -p 8080:8080 atlassian/jira-software`\n\n### Jira-specific settings\n\n* `ATL_AUTOLOGIN_COOKIE_AGE` (default: 1209600; two weeks, in seconds)\n\n The maximum time a user can remain logged-in with 'Remember Me'.\n\n### S3 Avatars storage configuration\nStarting with Jira 9.9, you can configure Jira to store avatar files in Amazon S3. For requirements and additional \ninformation, please refer to \n[Configuring Amazon S3 Object Storage](https://confluence.atlassian.com/pages/viewpage.action?spaceKey=JSERVERM&title=.Configuring+Amazon+S3+object+storage+vJira_admin_9.9).\n\n* `ATL_S3AVATARS_BUCKET_NAME`\n\n Bucket name to store avatars.\n\n* `ATL_S3AVATARS_REGION`\n\n AWS region where the S3 bucket is located.\n\n* `ATL_S3AVATARS_ENDPOINT_OVERRIDE`\n\n Override the default AWS API endpoint with a custom one (optional).\n\n### OpenSearch configuration\n\nStarting with Jira 11.2, you can configure Jira to use OpenSearch as the search platform.\nFor the full list of available OpenSearch properties and requirements, see\n[Configuring OpenSearch for Jira](https://confluence.atlassian.com/adminjiraserver/configuring-opensearch-for-jira-1620511851.html).\n\nOpenSearch properties are injected into `jira-config.properties` using\n`ADDITIONAL_JIRA_CONFIG_*` environment variables (see\n[Custom `jira-config.properties`](#custom-jira-configproperties) for details on\nthe mechanism).\n\nThe minimum required properties are:\n\n* `search.platform`\n\n The search platform to use. Set to `opensearch` to enable OpenSearch.\n\n* `opensearch.http.url`\n\n HTTP(S) URL of the OpenSearch cluster, or multiple URLs separated by commas.\n\n* `opensearch.username`\n\n Username for the OpenSearch cluster.\n\n* `opensearch.password`\n\n Password for the OpenSearch cluster.\n\nThe `__EXPAND_ENV` suffix lets you keep the password in a separate environment\nvariable rather than embedding it directly in the property line. In the example\nbelow `MY_OPENSEARCH_PASSWORD` is passed inline for brevity:\n\n```bash\ndocker run \\\n -e MY_OPENSEARCH_PASSWORD=my-secret \\\n -e ADDITIONAL_JIRA_CONFIG_01=\"search.platform=opensearch\" \\\n -e ADDITIONAL_JIRA_CONFIG_02=\"opensearch.http.url=http://opensearch-host:9200\" \\\n -e ADDITIONAL_JIRA_CONFIG_03=\"opensearch.username=admin\" \\\n -e ADDITIONAL_JIRA_CONFIG_04__EXPAND_ENV=\"opensearch.password={MY_OPENSEARCH_PASSWORD}\" \\\n atlassian/jira-software:latest\n```\n\n!!! warning \"Sensitive values on the command line\"\n Passing secrets via `-e` exposes them in shell history, process listings,\n and `docker inspect` output. In production, use `--env-file` with a\n permission-protected file or an external secrets manager to supply\n `MY_OPENSEARCH_PASSWORD`.\n\n### S3 Attachments storage configuration\nStarting with Jira 9.9, you can configure Jira to [store attachment files in Amazon S3](https://confluence.atlassian.com/adminjiraserver/storing-attachments-in-amazon-s3-1282250191.html). For requirements and additional\ninformation, please refer to [Configuring Amazon S3 Object Storage](https://confluence.atlassian.com/pages/viewpage.action?spaceKey=JSERVERM&title=.Configuring+Amazon+S3+object+storage+vJira_admin_9.9).\n\n* `ATL_S3ATTACHMENTS_BUCKET_NAME`\n\n Bucket name to store avatars.\n\n* `ATL_S3ATTACHMENTS_REGION`\n\n AWS region where the S3 bucket is located.\n\n* `ATL_S3ATTACHMENTS_ENDPOINT_OVERRIDE`\n\n Override the default AWS API endpoint with a custom one (optional).\n\nAvatars and attachments can be stored in the same bucket. If bucket names are identical, `ATL_S3AVATARS_*` env vars are used to generate a common filestore configuration.\n\n### S3 Backups storage configuration\n\nStarting with 9.16, you can configure Jira to [store backups in Amazon S3](https://confluence.atlassian.com/adminjiraserver/storing-backups-in-amazon-s3-1402409182.html).\n\n* `ATL_S3BACKUPS_BUCKET_NAME`\n\n Bucket name to store avatars.\n\n* `ATL_S3BACKUPS_REGION`\n\n AWS region where the S3 bucket is located.\n\n* `ATL_S3BACKUPS_ENDPOINT_OVERRIDE`\n\n Override the default AWS API endpoint with a custom one (optional).\n\n\n### Database configuration\n\nIt is optionally possible to configure the database from the environment,\navoiding the need to do so through the web startup screen.\n\nThe following variables are all must all be supplied if using this feature:\n\n* `ATL_JDBC_URL`\n\n The database URL; this is database-specific.\n\n* `ATL_JDBC_USER`\n\n The database user to connect as.\n\n* `ATL_JDBC_PASSWORD`\n\n The password for the database user.\n\n* `ATL_DB_DRIVER`\n\n The JDBC driver class; supported drivers are:\n\n * `com.microsoft.sqlserver.jdbc.SQLServerDriver`\n * `com.mysql.jdbc.Driver`\n * `oracle.jdbc.OracleDriver`\n * `org.postgresql.Driver`\n\n The driver must match the DB type (see next entry).\n\n* `ATL_DB_TYPE`\n\n The type of database; valid supported values are:\n\n * `mssql`\n * `mysql`\n * `mysql57`\n * `mysql8`\n * `oracle10g`\n * `postgres72`\n\n???+ note \"MySQL supportability\"\n `mysql` is only supported for versions prior to 8.13, and `mysql57` and `mysql8` are only supported after. \n See [the 8.13.x upgrade instructions](https://confluence.atlassian.com/jirasoftware/jira-software-8-13-x-upgrade-notes-1018783378.html)\n for details.\n\nThe following variables may be optionally supplied when configuring the\ndatabase from the environment:\n\n* `ATL_DB_SCHEMA_NAME`\n\n The schema name of the database. Depending on the value of `ATL_DB_TYPE`,\n the following default values are used if no schema name is specified:\n\n * `mssql`: `dbo`\n * `mysql`: NONE\n * `mysql57`: NONE\n * `mysql8`: NONE\n * `oracle10g`: NONE\n * `postgres72`: `public`\n\n???+ note \"MySQL or Oracle JDBC drivers\"\n Due to licensing restrictions Jira does not ship with MySQL or Oracle JDBC drivers. \n To use these databases you will need to copy a suitable driver into the container and restart it. \n For example, to copy the MySQL driver into a container named \"jira\", you would do the following:\n\n `docker cp mysql-connector-java.x.y.z.jar jira:/opt/atlassian/jira/lib`\n\n `docker restart jira`\n\nFor more information see the page\n[Startup check: JIRA database driver missing](https://confluence.atlassian.com/jirakb/startup-check-jira-database-driver-missing-873872169.html).\n\n#### Optional database settings\n\n* `ATL_JDBC_SECRET_CLASS`\n\n [Encryption class](https://confluence.atlassian.com/adminjiraserver/encrypting-database-password-974378811.html) for the database password. Depending on the secret class, the value of `ATL_JDBC_PASSWORD` will differ. Defaults to plaintext.\n\n Starting from 9.11 [AWS SecretsManager](https://confluence.atlassian.com/adminjiraserver/configuring-aws-secrets-manager-1282250155.html) is supported.\n\n**IMPORTANT:** to start using password encryption for Jira instances that have already been set up, make sure `ATL_FORCE_CFG_UPDATE` is set to true\nwhich will force the image entrypoint to regenerate `dbconfig.xml` with the new properties. Other database environment variables must be also set in the container:\n\n```shell\ndocker run -v jiraVolume:/var/atlassian/application-data/jira --name='jira' -d -p 8080:8080 \\\n -e ATL_JDBC_URL=jdbc:postgresql://172.17.0.1:5432/jira \\\n -e ATL_JDBC_USER='jira' -e ATL_DB_DRIVER='org.postgresql.Driver' \\\n -e ATL_DB_TYPE='postgres72' \\\n -e ATL_JDBC_SECRET_CLASS='com.atlassian.secrets.store.aws.AwsSecretsManagerStore' \\\n -e ATL_JDBC_PASSWORD='{\"region\": \"us-east-1\", \"secretId\": \"mysecret\", \"secretPointer\": \"/password\"}' \\\n -e ATL_FORCE_CFG_UPDATE='true' atlassian/jira-software\n```\n\nThe following variables are for the Tomcat JDBC connection pool, and are\noptional. For more information on these see: https://tomcat.apache.org/tomcat-7.0-doc/jdbc-pool.html\n\n* `ATL_DB_MAXIDLE` (default: 20)\n* `ATL_DB_MAXWAITMILLIS` (default: 30000)\n* `ATL_DB_MINEVICTABLEIDLETIMEMILLIS` (default: 5000)\n* `ATL_DB_MINIDLE` (default: 10)\n* `ATL_DB_POOLMAXSIZE` (default: 100)\n* `ATL_DB_POOLMINSIZE` (default: 20)\n* `ATL_DB_REMOVEABANDONED` (default: true)\n* `ATL_DB_REMOVEABANDONEDTIMEOUT` (default: 300)\n* `ATL_DB_TESTONBORROW` (default: false)\n* `ATL_DB_TESTWHILEIDLE` (default: true)\n* `ATL_DB_TIMEBETWEENEVICTIONRUNSMILLIS` (default: 30000)\n* `ATL_DB_VALIDATIONQUERY` (default: select 1)\n\nThe following settings only apply when using the Postgres driver:\n\n* `ATL_DB_KEEPALIVE` (default: true)\n* `ATL_DB_SOCKETTIMEOUT` (default: 240)\n\nThe following settings only apply when using the MySQL driver:\n\n* `ATL_DB_VALIDATIONQUERYTIMEOUT` (default: 3)\n\n### Data Center configuration\n\nThis docker image can be run as part of a\n[Data Center](https://confluence.atlassian.com/enterprise/jira-data-center-472219731.html)\ncluster. You can specify the following properties to start Jira as a Data Center\nnode, instead of manually configuring a cluster.properties file, See\n[Installing Jira Data Center](https://confluence.atlassian.com/adminjiraserver071/installing-jira-data-center-802592197.html)\nfor more information on each property and its possible configuration.\n\n#### Cluster configuration\n\n*Jira Software and Jira Service Management only*\n\n* `CLUSTERED` (default: false)\n\n Set 'true' to enable clustering configuration to be used. This will create a\n `cluster.properties` file inside the container's `$JIRA_HOME` directory.\n\n* `JIRA_NODE_ID` (default: jira_node_)\n\n The unique ID for the node. By default, this includes a randomly generated ID\n unique to each container, but can be overridden with a custom value.\n\n* `JIRA_SHARED_HOME` (default: $JIRA_HOME/shared)\n\n The location of the shared home directory for all Jira nodes. **Note**: This\n must be real shared filesystem that is mounted inside the\n container. Additionally, see the note about UIDs.\n\n* `EHCACHE_PEER_DISCOVERY` (default: default)\n\n Describes how nodes find each other.\n\n* `EHCACHE_LISTENER_HOSTNAME` (default: NONE)\n\n The hostname of the current node for cache communication. Jira Data Center\n will resolve this this internally if the parameter isn't set.\n\n* `EHCACHE_LISTENER_PORT` (default: 40001)\n\n The port the node is going to be listening to. Depending on your container\n deployment method this port may need to be [exposed and published][docker-expose].\n\n* `EHCACHE_OBJECT_PORT` (default: dynamic)\n\n The port number on which the remote objects bound in the registry receive\n calls. This defaults to a free port if not specified. This port may need to\n be [exposed and published][docker-expose].\n\n* `EHCACHE_LISTENER_SOCKETTIMEOUTMILLIS` (default: 2000)\n\n The default timeout for the Ehcache listener.\n\n* `EHCACHE_MULTICAST_ADDRESS` (default: NONE)\n\n A valid multicast group address. Required when EHCACHE_PEER_DISCOVERY is set\n to 'automatic' instead of 'default'.\n\n* `EHCACHE_MULTICAST_PORT` (default: NONE)\n\n The dedicated port for the multicast heartbeat traffic. Required when\n EHCACHE_PEER_DISCOVERY is set to 'automatic' instead of 'default'. Depending\n on your container deployment method this port may need to be\n [exposed and published][docker-expose].\n\n* `EHCACHE_MULTICAST_TIMETOLIVE` (default: NONE)\n\n A value between 0 and 255 which determines how far the packets will\n propagate. Required when EHCACHE_PEER_DISCOVERY is set to 'automatic' instead\n of 'default'.\n\n* `EHCACHE_MULTICAST_HOSTNAME` (default: NONE)\n\n The hostname or IP of the interface to be used for sending and receiving\n multicast packets. Required when EHCACHE_PEER_DISCOVERY is set to 'automatic'\n instead of 'default'.\n\n#### Shared directory and user IDs\n\nBy default, the Jira application runs as the user `jira`, with a UID and GID\nof 2001. Consequently, this UID must have write access to the shared\nfilesystem. If for some reason a different UID must be used, there are a number\nof options available:\n\n* The Docker image can be rebuilt with a different UID.\n* Under Linux, the UID can be remapped using\n [user namespace remapping](https://docs.docker.com/engine/security/userns-remap/).\n\nTo preserve strict permissions for certain configuration files, this container starts as\n`root` to perform bootstrapping before running Jira under a non-privileged user account.\nIf you wish to start the container as a non-root user, please note that Tomcat\nconfiguration will be skipped and a warning will be logged. You may still apply custom\nconfiguration in this situation by mounting a custom server.xml file directly to\n`/opt/atlassian/jira/conf/server.xml`\n\nDatabase and Clustering bootstrapping will work as expected when starting this container\nas a non-root user.\n\n### Container configuration\n\n* `ATL_FORCE_CFG_UPDATE` (default: false)\n\n The Docker [entrypoint][entrypoint.py] generates application configuration on\n first start; not all of these files are regenerated on subsequent\n starts. This is deliberate, to avoid race conditions or overwriting manual\n changes during restarts and upgrades. However in deployments where\n configuration is purely specified through the environment (e.g. Kubernetes)\n this behaviour may be undesirable; this flag forces an update of all\n generated files.\n\n In Jira the affected files are: `dbconfig.xml`\n\n See [the entrypoint code][entrypoint.py] for the details of how configuration\n files are generated.\n\n* `ATL_ALLOWLIST_SENSITIVE_ENV_VARS`\n\n Define a comma separated list of environment variables containing keywords 'PASS', 'SECRET' or 'TOKEN' to be ignored by the unset function which is executed in the entrypoint. The function uses `^` regex. For example, if you set `ATL_ALLOWLIST_SENSITIVE_ENV_VARS=\"PATH_TO_SECRET_FILE\"`, all variables starting with `PATH_TO_SECRET_FILE` will not be unset.\n\n???+ warning \"Value exposure on host OS\"\n When using this property, the values to sensitive environment variables will be available in clear text on the \n host OS. As such, this data may be exposed to users or processes running on the host OS.\n\n* `SET_PERMISSIONS` (default: true)\n\n Define whether to set home directory permissions on startup. Set to `false` to disable\n this behaviour.\n\n* `ATL_UNSET_SENSITIVE_ENV_VARS` (default: true)\n\n Define whether to unset environment variables containing keywords 'PASS', 'SECRET' or 'TOKEN'.\n The unset function is executed in the entrypoint. Set to `false` if you want to allow passing\n sensitive environment variables to Jira container.\n\n???+ warning \"Value exposure on host OS\"\n When using this property, the values to sensitive environment variables will be available in clear text on the \n host OS. As such, this data may be exposed to users or processes running on the host OS.\n\n* `ATL_JIRA_CLEAR_PLUGIN_CACHE`\n \n When set to true, plugin cache at `${JIRA_HOME}/plugins/.bundled-plugins` and `${JIRA_HOME}/plugins/.osgi-plugins`\n will be deleted before Jira starts. Once set, make sure to unset this environment variable if you don't want Jira plugin cache to be flushed\n every time the container starts.\n \n See: [How to clear Jira's plugin cache](https://confluence.atlassian.com/jirakb/how-to-clear-jira-s-plugin-cache-1157468195.html).\n\n* `ATL_JIRA_SESSION_TIMEOUT`\n\n The default Tomcat session timeout (in minutes) for all newly created sessions which is set in web.xml. Defaults to 30.\n\n### Custom `jira-config.properties`\n\nAdditional properties can be injected into `jira-config.properties` using\nenvironment variables prefixed with `ADDITIONAL_JIRA_CONFIG_`.\n\nEach variable's value must be a complete property line in `key=value` format.\nEnvironment variable names are sorted for consistent file generation; order has\nno effect on runtime behavior.\n\n```bash\ndocker run \\\n -e ADDITIONAL_JIRA_CONFIG_01=\"jira.websudo.is.disabled=true\" \\\n -e ADDITIONAL_JIRA_CONFIG_02=\"jira.lf.top.bgcolour=#003366\" \\\n atlassian/jira-software:latest\n```\n\n#### How properties are written\n\nThe properties are written to a clearly marked auto-generated section at the end\nof the file. Any manually added content outside this section is preserved across\ncontainer restarts.\n\n#### Injecting secrets via `__EXPAND_ENV`\n\nFor values that reference secrets stored in separate environment variables\n(common in Kubernetes where secrets are mounted as env vars), use the\n`__EXPAND_ENV` suffix. Placeholders in `{VAR_NAME}` format are replaced with\nthe corresponding environment variable value at startup:\n\n```bash\ndocker run \\\n -e MY_OPENSEARCH_PASSWORD=my-secret \\\n -e ADDITIONAL_JIRA_CONFIG_01=\"search.platform=opensearch\" \\\n -e ADDITIONAL_JIRA_CONFIG_02__EXPAND_ENV=\"opensearch.password={MY_OPENSEARCH_PASSWORD}\" \\\n atlassian/jira-software:latest\n```\n\nThis generates the following in `jira-config.properties`:\n\n```properties\n# ---- AUTO GENERATED ADDITIONAL PROPERTIES FROM DOCKER IMAGE ---\n# DO NOT MODIFY this section - it is auto-generated during container startup\n# from ADDITIONAL_JIRA_CONFIG_* environment variables\nsearch.platform=opensearch\nopensearch.password=my-secret\n# ---- END OF AUTO GENERATED ADDITIONAL PROPERTIES ---\n```\n\nIf a referenced environment variable is not set, the placeholder is left\nunchanged and a warning is logged.\n\n#### Limitations and requirements\n\n* **Local home directory only**: `jira-config.properties` is written to\n `$JIRA_HOME` which must be the node-local home directory (not shared storage).\n Using `ADDITIONAL_JIRA_CONFIG_*` when `jira-config.properties` is stored on a\n shared filesystem (e.g. NFS, EFS) may cause unexpected outcomes due to update\n races across different container instances during rolling deployments.\n\n* **Read-only mounts not supported**: If `jira-config.properties` is mounted as\n a read-only file (e.g. via a Kubernetes ConfigMap volume mount), the\n `ADDITIONAL_JIRA_CONFIG_*` variables will have no effect. A warning is logged\n in this case. Manage the file content entirely through the mount instead — do\n not combine both approaches.\n\n* **Auto-generated section**: The generated properties are placed inside clearly\n marked comment boundaries at the end of the file. Manual edits outside these\n markers are preserved. Do not edit content within the markers — it will be\n overwritten on the next container startup.\n\n| Aspect | Detail |\n|-------------------------|-------------------------------------------------------------|\n| Env var prefix | `ADDITIONAL_JIRA_CONFIG_` |\n| Secret expansion suffix | `__EXPAND_ENV` (double underscore) |\n| Target file | `$JIRA_HOME/jira-config.properties` |\n| Ordering | Sorted for reproducibility; order has no effect on behavior |\n| Existing content | Preserved (only auto-generated section is replaced) |\n| No matching env vars | File is not created; stale section is removed if present |\n\n### Advanced Configuration\n\nAs mentioned at the top of this section, the settings from the environment are\nused to populate the application configuration on the container startup. However,\nin some cases you may wish to customise the settings in ways that are not\nsupported by the environment variables above. In this case, it is possible to\nmodify the base templates to add your own configuration. There are three main\nways of doing this; modify our repository to your own image, build a new image\nfrom the existing one, or provide new templates at startup. We will briefly\noutline these methods here, but in practice how you do this will depend on your\nneeds.\n\n##### Building your own image\n\n* Clone the Atlassian repository at https://bitbucket.org/atlassian-docker/docker-atlassian-jira/\n* Modify or replace the [Jinja](https://jinja.palletsprojects.com/) templates\n under `config`; _NOTE_: The files must have the `.j2` extensions. However you\n don't have to use template variables if you don't wish.\n* Build the new image with e.g: `docker build --tag my-jira-8-image --build-arg JIRA_VERSION=8.x.x .`\n* Optionally push to a registry, and deploy.\n\n##### Build a new image from the existing one\n\n* Create a new `Dockerfile`, which starts with the line e.g: `FROM\n atlassian/jira-software:latest`.\n* Use a `COPY` line to overwrite the provided templates.\n* Build, push and deploy the new image as above.\n\n##### Overwrite the templates at runtime\n\nThere are two main ways of doing this:\n\n* If your container is going to be long-lived, you can create it, modify the\n installed templates under `/opt/atlassian/etc/`, and then run it.\n* Alternatively, you can create a volume containing your alternative templates,\n and mount it over the provided templates at runtime\n with `--volume my-config:/opt/atlassian/etc/`.\n\n## Logging\n\nBy default the Jira logs are written inside the container, under\n`${JIRA_HOME}/logs/`. If you wish to expose this outside the container (e.g. to\nbe aggregated by logging system) this directory can be a data volume or bind\nmount. Additionally, Tomcat-specific logs are written to\n`/opt/atlassian/jira/logs/`.\n\n## Upgrades\n\nTo upgrade to a more recent version of Jira you can simply stop the `jira` container and start a new one based on a more recent image:\n\n```shell\ndocker stop jira\ndocker rm jira\ndocker run ... (See above)\n```\n\nAs your data is stored in the data volume directory on the host it will still be available after the upgrade.\n\n!!! note \"Please make sure that you **don't** accidentally remove the `jira` container and its volumes using the `-v` option.\"\n\n## Backup\n\nFor evaluations you can use the built-in database that will store its files in the Jira home directory. In that case it is sufficient to create a backup archive of the docker volume.\n\nIf you're using an external database, you can configure Jira to make a backup automatically each night. This will back up the current state, including the database to the `jiraVolume` docker volume, which can then be archived. Alternatively you can backup the database separately, and continue to create a backup archive of the docker volume to back up the Jira Home directory.\n\nRead more about data recovery and backups: [https://confluence.atlassian.com/adminjiraserver071/backing-up-data-802592964.html](https://confluence.atlassian.com/adminjiraserver071/backing-up-data-802592964.html)\n\n## Shutdown\n\nDepending on your configuration Jira may take a short period to shutdown any\nactive operations to finish before termination. If sending a `docker stop` this\nshould be taken into account with the `--time` flag.\n\nAlternatively, the script `/shutdown-wait.sh` is provided, which will initiate a\nclean shutdown and wait for the process to complete. This is the recommended\nmethod for shutdown in environments which provide for orderly shutdown,\ne.g. Kubernetes via the `preStop` hook.\n\n## Versioning\n\nThe `latest` tag matches the most recent release of Atlassian Jira Software, Jira Core or Jira Service Management. Thus `atlassian/jira-software:latest` will use the newest version of Jira available.\n\nAlternatively you can use a specific major, major.minor, or major.minor.patch version of Jira by using a version number tag:\n\n* `atlassian/jira-software:8`\n* `atlassian/jira-software:8.14`\n* `atlassian/jira-software:8.14.0`\n\n* `atlassian/jira-servicemanagement:4`\n* `atlassian/jira-servicemanagement:4.14`\n* `atlassian/jira-servicemanagement:4.14.0`\n\n* `atlassian/jira-core:8`\n* `atlassian/jira-core:8.14`\n* `atlassian/jira-core:8.14.0`\n\nAll Jira versions from 7.13+ (Software/Core) / 3.16+ (Service Management) are available.\n\n???+ warning \"`atlassian/jira-servicedesk` deprecation\"\n All Jira Service Management 4.x versions are also available as `atlassian/jira-servicedesk`. \n This namespace has been deprecated and versions from 5+ onwards will only be available as `atlassian/jira-servicemanagement`.\n\n## Supported JDK versions and base images\n\nAtlassian Docker images are generated from either\n[official Eclipse Temurin OpenJDK Docker images](https://hub.docker.com/_/eclipse-temurin) or [Red Hat Universal Base Images](https://catalog.redhat.com/software/containers/ubi9/openjdk-17/61ee7c26ed74b2ffb22b07f6?architecture=amd64). \n\nUBI based images are only published from Jira 9.5 onwards and JDK17 only. Tags are available in 2 formats: `-ubi9` and `-ubi9-jdk17`.\n\nThe Docker images follow the [Atlassian Support end-of-life\npolicy](https://confluence.atlassian.com/support/atlassian-support-end-of-life-policy-201851003.html);\nimages for unsupported versions of the products remain available but will no longer\nreceive updates or fixes.\n\nHistorically, we have also generated other versions of the images, including\nJDK8, Alpine, and 'slim' versions of the JDK. These legacy images still exist in\nDocker Hub, however they should be considered deprecated, and do not receive\nupdates or fixes.\n\nIf for some reason you need a different version, see [Building your own image](#building-your-own-image) above.\n\n## Migration to UBI\n\nIf you have been mounting any files to `${JAVA_HOME}` directory in `eclipse-temurin` based container, `JAVA_HOME` in UBI JDK17 container is set to `/usr/lib/jvm/java-17`.\n\nAlso, if you have been mounting and running any custom scripts in the container, UBI-based images may lack some tools and utilities that are available out of the box in eclipse-temurin tags. If that's the case, see [Building your own image](#building-your-own-image).\n\n## Supported architectures\n\nCurrently, Jira and JSM container images are built for the `linux/amd64` and `linux/arm64` target platforms.\nThe Dockerfiles and support tooling have now had all\narchitecture-specific components removed, so if necessary it is possible to\nbuild images for any platform supported by OCI-compliant container runtimes.\n\n### Building on the target architecture\n\nNote: This method is known to work on Mac M1 and AWS ARM64 machines, but has not\nbeen extensively tested.\n\nThe simplest method of getting a platform image is to build it on a target\nmachine. The following assumes you have git and Docker installed. You will also\nneed to know which version of Jira you want to build; substitute\n`JIRA_VERSION=x.x.x` with your required version:\n\n```shell\ngit clone --recurse-submodule https://bitbucket.org/atlassian-docker/docker-atlassian-jira.git\ncd docker-atlassian-jira\ndocker build --tag my-image --build-arg JIRA_VERSION=x.x.x .\n```\nThis image can be pushed up to your own Docker Hub or private repository.\n\n## Troubleshooting\n\nThese images include built-in scripts to assist in performing common JVM diagnostic tasks.\n\n### Thread dumps\n\n`/opt/atlassian/support/thread-dumps.sh` can be run via `docker exec` to easily trigger the collection of thread\ndumps from the containerized application. For example:\n\n```shell\ndocker exec my_container /opt/atlassian/support/thread-dumps.sh\n```\n\nBy default, this script will collect 10 thread dumps at 5 second intervals. This can\nbe overridden by passing a custom value for the count and interval, by using `-c` / `--count`\nand `-i` / `--interval` respectively. For example, to collect 20 thread dumps at 3 second intervals:\n\n```shell\ndocker exec my_container /opt/atlassian/support/thread-dumps.sh --count 20 --interval 3\n```\n\nThread dumps will be written to `$APP_HOME/thread_dumps/`.\n\n???+ note \"Disable capturing output from top run\"\n By default this script will also capture output from top run in 'Thread-mode'. This can\n be disabled by passing `-n` / `--no-top`\n\n### Heap dump\n\n`/opt/atlassian/support/heap-dump.sh` can be run via `docker exec` to easily trigger the collection of a heap\ndump from the containerized application. For example:\n\n```shell\ndocker exec my_container /opt/atlassian/support/heap-dump.sh\n```\n\nA heap dump will be written to `$APP_HOME/heap.bin`. If a file already exists at this\nlocation, use `-f` / `--force` to overwrite the existing heap dump file.\n\n### Manual diagnostics\n\nThe `jcmd` utility is also included in these images and can be used by starting a `bash` shell\nin the running container:\n\n```shell\ndocker exec -it my_container /bin/bash\n```\n\n## Support\n\nFor product support, go to:\n\n* https://support.atlassian.com/jira-software-server/\n* https://support.atlassian.com/jira-service-management-server/\n* https://support.atlassian.com/jira-core-server/\n\nYou can also visit the [Atlassian Data Center](https://community.atlassian.com/t5/Atlassian-Data-Center-on/gh-p/DC_Kubernetes)\nforum for discussion on running Atlassian Data Center products in containers.\n\n## Development and testing\n\nSee [Development][DEVELOPMENT.md] for details on setting up a development\nenvironment and running tests.\n\n## Changelog\n\nFor a detailed list of changes to the Docker image configuration see [the Git\ncommit history](https://bitbucket.org/atlassian-docker/docker-atlassian-jira/commits/).\n\n## License\n\nCopyright © 2020 Atlassian Corporation Pty Ltd.\nLicensed under the Apache License, Version 2.0.\n\n[docker-expose]: https://docs.docker.com/v17.09/engine/userguide/networking/default_network/binding/\n[entrypoint.py]: https://bitbucket.org/atlassian-docker/docker-atlassian-jira/src/master/entrypoint.py\n[DEVELOPMENT.md]: https://bitbucket.org/atlassian-docker/docker-atlassian-jira/src/master/DEVELOPMENT.md\n" }, { "path": "docs/docs/examples/.pages", "content": "collapse_single_pages: true\nnav:\n - EXAMPLES.md\n - Kubernetes cluster: cluster\n - database\n - ingress\n - storage\n - bamboo\n - bitbucket\n - confluence\n - jira\n - logging\n - ...\n" }, { "path": "docs/docs/examples/EXAMPLES.md", "content": "# Available examples \n\n!!!warning \"Support disclaimer\"\n Use the examples we provide as reference only, we don’t offer official support for them. \n\n## Pre-requisites\n\n### :material-kubernetes: Kubernetes clusters \nSee examples of provisioning Kubernetes clusters on cloud-based providers:\n \n * [Amazon EKS](cluster/EKS_SETUP.md) \n * [Google GKE](cluster/GKE_SETUP.md)\n * [Azure AKS](cluster/AKS_SETUP.md)\n\n### :material-directions-fork: Ingress\n* See an example of [provisioning an NGINX Ingress controller](ingress/INGRESS_NGINX.md)\n\n### :material-database: Database\n* See an example of [creating an Amazon RDS database instance](database/AMAZON_RDS.md)\n\n### :material-folder-network: Storage\n=== \"AWS EBS\"\n\n * See an example of [local storage utilizing AWS EBS-backed volumes](storage/aws/LOCAL_STORAGE.md)\n\n=== \"AWS EFS\"\n\n * See an example of [shared storage utilizing AWS EFS-backed filesystem](storage/aws/SHARED_STORAGE.md)\n\n=== \"NFS\"\n\n * See an example of [standing up an NFS server for Bitbucket](storage/nfs/NFS.md)\n\n## Bamboo\n\n### :material-lan-pending: Remote agents\n* See an example of deploying a [remote agent for Bamboo](bamboo/REMOTE_AGENTS.md)\n\n## Bitbucket\n\n### :material-file-search-outline: Elasticsearch\n* See an example of [standing up an Elasticsearch instance for Bitbucket](bitbucket/BITBUCKET_ELASTICSEARCH.md)\n\n### :material-mirror-variant: Smart Mirrors\n* See an example of [Bitbucket Smart Mirrors](bitbucket/BITBUCKET_MIRRORS.md)\n\n### :material-remote-desktop: SSH\n* See an example of [SSH service in Bitbucket on Kubernetes](bitbucket/BITBUCKET_SSH.md)\n\n### :material-remote-desktop: Mesh\n* See an example of [Bitbucket Mesh on Kubernetes](bitbucket/BITBUCKET_MESH.md)\n\n## Other\n\n### :material-file-document-edit: Logging\n* See an example of [how to deploy an EFK stack to Kubernetes](logging/efk/EFK.md)\n\n### :simple-prometheus: Prometheus Monitoring\n* See an example of [how to monitor DC products with Prometheus](../userguide/monitoring/PROMETHEUS.md)\n\n### :material-checkbox-multiple-marked-outline: Customization\n* See an example of [External libraries and plugins](external_libraries/EXTERNAL_LIBS.md)\n" }, { "path": "docs/docs/examples/bamboo/.pages", "content": "collapse_single_pages: false\nnav:\n - REMOTE_AGENTS.md\n - AGENT_CAPABILITIES.md\n - ..." }, { "path": "docs/docs/examples/bamboo/AGENT_CAPABILITIES.md", "content": "# Agent capabilities\n\nA capability is a feature of an agent. A capability can be defined on an agent for:\n\n* an executable (e.g. Maven)\n* a JDK\n* a Version Control System client application (e.g. Git)\n\nYou can learn more about remote agents capabilities on the [official documentation page](https://confluence.atlassian.com/bamboo/configuring-capabilities-289277148.html){.external}.\n\n## Custom capabilities\n\n!!!info \"Default capabilities\"\n\n By default the Bamboo agent Helm chart will deploy the [bamboo-agent-base](https://hub.docker.com/r/atlassian/bamboo-agent-base){.external} Docker image. This image provides the following capabilities out of the box:\n \n * JDK 11\n * Git & Git LFS\n * Maven 3\n * Python 3\n\nIf additional capabilities are required, the [Bamboo agent base Docker image](https://bitbucket.org/atlassian-docker/docker-bamboo-agent-base/src/master/){.external} can be extended with those capabilities. \n\nThis custom image can be used, by first updating the Bamboo agent `values.yaml` with the image `tag` of the custom Docker image i.e.\n\n```yaml\nimage:\n repository: hoolicorp/bamboo-agent-base\n pullPolicy: IfNotPresent\n tag: \"ruby-agent\"\n```\n\nThe custom agent can then be deployed via Helm:\n\n```shell\nhelm install ruby-agent atlassian-data-center/bamboo-agent -f ruby-agent.yaml\n```" }, { "path": "docs/docs/examples/bamboo/REMOTE_AGENTS.md", "content": "# Remote agents\n\nRemote agents can be provisioned to a Kubernetes cluster to run jobs delegated to them via a Bamboo server. An agent can run a job if its capabilities match the requirements of a job. Each job inherits the requirements from individual tasks that it contains.\n\nYou can learn more details about remote agents on the [official documentation page](https://confluence.atlassian.com/bamboo/agents-and-capabilities-289277114.html).\n\n## Requirements\n\n!!!warning \"Bamboo server prerequisites\"\n\n * The Bamboo server instance must use a valid Bamboo Data Center instance license and be fully configured\n * The Bamboo server instance must have `security token verification` **enabled**\n * The Bamboo server instance must have `remote agent authentication` **disabled**\n\n## Deployment\n\nSteps required for deploying a remote agent\n\n1. Configure Bamboo server for remote agent support\n2. Deploy agent\n\n### 1. Configure Bamboo server\n\nThere are 2 approaches for doing this:\n\n* Automatically when deploying Bamboo server\n* Manually via Bamboo server agent settings\n\n#### Automatically\n\nWhen initially deploying Bamboo server its `values.yaml` can be configured to:\n\n* disable `remote agent authentication`\n* define a custom `security token` \n\nThis will allow remote agents that are configured with the same security token to automatically join the cluster. \n\nFirst, create a secret to store a custom security token with which remote agent(s) should authenticate to the Bamboo server. \n\n!!!info \"Security token format\"\n \n The security token should be set to a 40-character hexadecimal string. The following command can be used to generate a string in this format:\n ```\n xxd -l 20 -p /dev/urandom\n ```\n\nAdd the generated string (security token) to a K8s secret\n\n ``` shell\n kubectl create secret generic security-token --from-literal=security-token=\n ```\n\nUpdate the Bamboo `values.yaml` with this secret and disable agent authentication:\n\n```yaml\nbamboo:\n securityToken:\n secretName: \"security-token\"\n secretKey: security-token\n disableAgentAuth: true\n```\n\n!!!warning \"Disabling remote agent authentication\"\n\n when setting the property `disableAgentAuth` to `true` this will have the effect of automatically allowing agents with the correct security token to communicate with the Bamboo server. This property is useful for testing, and when deployments requiring many agents are needed. This property can also be left in its default state of `false` in which case each agent will need to be approved manually via the `Agents` settings tab of the Bamboo server instance. Additional details on agent authentication can be found [here](https://confluence.atlassian.com/bamboo/agent-authentication-289277196.html) \n \n\n#### Manually\n\n* When logged into the Bamboo server instance, and from the `Agents` settings tab, **enable** `security token verification`, and **disable** `remote agent authentication`\n ![security_token_verification](../../assets/images/bamboo_agents/enable-disable.png){ width=\"900\" }\n \n* Navigate to the remote agent's installation page by selecting the `Install remote agent` button from the `Agents` settings tab\n ![install_remote_agent](../../assets/images/bamboo_agents/install-remote-agent.png){ width=\"900\" }\n\n* Create a K8s secret using the `security token` rendered on the `Installing a remote agent` page\n ![security_token](../../assets/images/bamboo_agents/security-token.png){ width=\"900\" }\n \n create secret using token...\n \n ``` shell\n kubectl create secret generic security-token --from-literal=security-token=\n ```\n\n### 2. Deploy agent \n\n* Update the bamboo agent `values.yaml` to utilize the security token secret and point to the bamboo server instance\n\n```yaml\nreplicaCount: 3\nagent:\n securityToken:\n secretName: \"security-token\"\n secretKey: security-token\n server: \"bamboo.bamboo.svc.cluster.local\"\n```\n\n!!!info \"Values\"\n\n * As long as your cluster has the physical resources the `replicaCount` can be set to any value from `1` .. `1 + n` \n * `agent.server` should be configured with the K8s DNS record for the Bamboo server service. The value should be of the form: `..svc.cluster.local`\n\n* Install the agent\n\n```shell\nhelm install bamboo-agent atlassian-data-center/bamboo-agent -f values.yaml\n```\n\n!!!tip \"Custom agents\"\n\n By default the Bamboo agent Helm chart will deploy the [bamboo-agent-base](https://hub.docker.com/r/atlassian/bamboo-agent-base){.external} Docker image. This image provides the following capabilities out of the box:\n \n * JDK 11\n * Git & Git LFS\n * Maven 3\n * Python 3\n\n For details on defining and deploying agents with custom/additional capabilities view the [agent capabilities guide](AGENT_CAPABILITIES.md)\n\n## Scaling the agent count\n\nThe number of active agents can be easily increased or decreased: \n\n``` shell\nhelm upgrade --set replicaCount= \\\n --reuse-values \\\n \n atlassian-data-center/bamboo-agent\n```\n\n## Troubleshooting\n\nYou can find the most common errors relating to agent configuration in the [official Bamboo agent documentation](https://confluence.atlassian.com/bamboo/bamboo-remote-agent-installation-guide-289276832.html){.external}.\n" }, { "path": "docs/docs/examples/bitbucket/.pages", "content": "nav:\n - OpenSearch : BITBUCKET_OPENSEARCH.md\n - Elasticsearch (Deprecated) : BITBUCKET_ELASTICSEARCH.md\n - Smart Mirrors : BITBUCKET_MIRRORS.md\n - SSH : BITBUCKET_SSH.md\n - Mesh : BITBUCKET_MESH.md\n - ...\n" }, { "path": "docs/docs/examples/bitbucket/BITBUCKET_AWS_OPENSEARCH.md", "content": "# Configure AWS OpenSearch with Bitbucket\n\n## Configuration Example\n\n```yaml\nbitbucket:\n # Disable default OpenSearch deployment\n opensearch:\n enabled: false\n\n # Configure AWS OpenSearch connection\n additionalEnvironmentVariables:\n - name: SEARCH_ENABLED\n value: \"true\"\n - name: PLUGIN_SEARCH_CONFIG_BASEURL\n value: \"https://your-opensearch-endpoint.region.es.amazonaws.com\"\n - name: PLUGIN_SEARCH_CONFIG_USERNAME\n valueFrom:\n secretKeyRef:\n name: aws-opensearch-credentials\n key: username\n - name: PLUGIN_SEARCH_CONFIG_PASSWORD\n valueFrom:\n secretKeyRef:\n name: aws-opensearch-credentials\n key: password\n```\n\n## Create AWS OpenSearch Credentials Secret\n\n```shell\nkubectl create secret generic aws-opensearch-credentials \\\n --from-literal=username=your-username \\\n --from-literal=password=your-password \\\n -n your-namespace\n``` " }, { "path": "docs/docs/examples/bitbucket/BITBUCKET_ELASTICSEARCH.md", "content": "!!!warning \"Elasticsearch deprecation notice\"\n Elasticsearch has been deprecated as a search platform for Bitbucket. Use [OpenSearch](../BITBUCKET_OPENSEARCH) instead.\n\n# Bitbucket Elasticsearch recommendations\nWhile Bitbucket has its own internal Elasticsearch instance, we highly recommend you use an external Elasticsearch installation, either within the Kubernetes cluster or, if available, an instance managed by your hosting provider.\n\n## Installing and configuring Elasticsearch in your Kubernetes cluster\n### Installing Elasticsearch into your Kubernetes cluster\nChoose a version of Elasticsearch that is supported by the [version of Bitbucket you are installing](https://confluence.atlassian.com/bitbucketserver/supported-platforms-776640981.html#Supportedplatforms-additional-toolsAdditionaltools){.external}. For Bitbucket 7.14 the latest supported Elasticsearch version is 7.9.3, so we will target that.\n\nThere are official [Helm charts for Elasticsearch 7.9.3](https://artifacthub.io/packages/helm/elastic/elasticsearch/7.9.3){.external}. Following the documentation there add the Elasticsearch Helm charts repository:\n\n```bash\nhelm repo add elastic https://helm.elastic.co\n```\nthen install it:\n```bash\nhelm install elasticsearch --namespace --set imageTag=\"7.9.3\" elastic/elasticsearch\n```\n!!! info \"Prerequisites of Elasticsearch Helm chart\"\n Running the above commands will install Elasticsearch with the default configuration, which is 3 worker nodes. \n However, it may not always work out of the box if failed to fulfill prerequisites for the default installation. \n Some example prerequisites include:\n\n * CPU/memory requests: 1000m/2Gi (for each worker node)\n * Preconfigured storage volumes (30Gi for each worker node)\n \n For more details refer to [Elasticsearch values.yaml file](https://github.com/elastic/helm-charts/blob/7.9/elasticsearch/values.yaml){.external}.\n\n### Configuring your Bitbucket deployment\n\nTo enable the installed Elasticsearch service you need to configure the service URL under `bitbucket:` stanza in the `values.yaml` file.\nCheck the Kubernetes official documentation on how to get [DNS record for a service](https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/#services){.external}.\n```yaml\nbitbucket:\n elasticSearch:\n baseUrl: http://elasticsearch-master..svc.cluster.local:9200\n```\nThis will also have the effect of disabling Bitbucket’s internal Elasticsearch instance.\n\n!!! info \"Elasticsearch security\"\n If you have Elasticsearch cluster with [security enabled](https://github.com/elastic/helm-charts/tree/master/elasticsearch#how-to-deploy-clusters-with-security-authentication-and-tls-enabled){.external}, i.e. having credential details stored in a Kubernetes secret and passed into `extraEnvs` as this [example](https://github.com/elastic/helm-charts/blob/master/elasticsearch/examples/security/values.yaml#L23){.external} does, you can then use the same secret and configure that in the bitbucket `values.yaml` file: \n ```yaml\n bitbucket:\n elasticSearch: \n credentials:\n secretName: \n usernameSecretKey: username\n passwordSecretKey: password\n ```\n Read about [Kubernetes secrets](https://kubernetes.io/docs/concepts/configuration/secret/){.external}.\n\n\n## Configuring Amazon Elasticsearch Service with Bitbucket on Kubernetes\n\n### Creating an Amazon Elasticsearch Service domain with a master user\n\nThe Elasticsearch instance (“domain”) can be created via the AWS CLI or the web console; for this example we will use the web console and a master user:\n\n1. In the EKS console navigate to **Your Cluster → Networking** and note the VPC ID.\n2. In the Elasticsearch console create a new domain:\n 1. Select a production deployment.\n 2. Select Elasticsearch version 7.9.\n3. In the next screen configure the AZs and nodes as appropriate for your expected workload.\n4. On the **Access and security** page:\n 1. Select the same VPC as the EKS cluster, as noted in step 1.\n 2. Select appropriate subnets for each AZ; private subnets are fine.\n 3. Select appropriate security groups that will grant node/pod access.\n 4. Tick **Fine–grained access control**:\n * Select **Create master user** and add a username and a strong password.\n5. Configure tags, etc. as appropriate for your organisation.\n\nOnce the Elasticsearch domain has finished creating, make a note of the **VPC Endpoint**, which will be an HTTPS URL.\n\n### Configuring your Bitbucket deployment\n\nTo use the managed Elasticsearch service, first create a Kubernetes secret using the username and password from step 4 above. Then configure the service URL under `bitbucket:` in the `values.yaml` file, substituting the values below from the above steps where appropriate:\n```yaml\nbitbucket:\n elasticSearch:\n baseUrl: \n credentials:\n secretName: \n usernameSecretKey: username\n passwordSecretKey: password\n```\n!!! info \"\"\n Read about [Kubernetes secrets](https://kubernetes.io/docs/concepts/configuration/secret/){.external}.\n\n## Testing your Elasticsearch connection\nTo test if Elasticsearch is properly set up, go to **Administration > System - Server settings**. The Elasticsearch URL should be pre-populated already in the search section. Click the **Test** button to see if it connects successfully.\n![bitbucket-elasticsearch](../../assets/images/bitbucket-elasticsearch.png)\n" }, { "path": "docs/docs/examples/bitbucket/BITBUCKET_MESH.md", "content": "# Bitbucket Mesh\n\nBitbucket Mesh is a distributed, replicated, and horizontally scalable Git repository storage system, which increases performance and improves the resilience of Bitbucket.\n\n![bitbucket_mesh](../../assets/images/bitbucket_with_mesh.png)\n\nYou can learn more details about Bitbucket Mesh on the [official documentation page](https://confluence.atlassian.com/bitbucketserver/bitbucket-mesh-1128304351.html){.external}.\n\n!!!tip \"Recommendations for Mesh deployments\"\n\n **Bitbucket version**\n\n By default, the Helm charts target the latest Bitbucket LTS version. However,\n Mesh is only supported from version 8.0. You will need to select an 8.x\n version of Bitbucket to deploy Mesh. Learn more details below.\n\n **Mesh agent version**\n\n Bitbucket Mesh agents are versioned independently from Bitbucket. You should\n select the appropriate version for the deployed version of Bitbucket. See\n the [Mesh download page](https://www.atlassian.com/software/bitbucket/download-mesh-archives){.external}\n for available versions.\n\n **Number of Mesh nodes**\n\n In order for high-availability to be possible, we recommend having a minimum\n of three Mesh nodes. There is no maximum on the number of nodes.\n\n **Mesh node co-location**\n\n We don't currently support deploying Mesh nodes into multiple\n availability zones. Just like the shared file system based deployments, the\n Mesh nodes (that is, the repository storage) and the application nodes must\n be co-located.\n\n **Other Mesh deployment requirements**\n\n For more details on the requirements and limitations of Mesh deployments, check the\n [the Bitbucket Mesh FAQ](https://confluence.atlassian.com/enterprise/bitbucket-data-center-faq-776663707.html#BitbucketDataCenterFAQ-Mesh){.external}.\n\n\n### Configuring your Bitbucket and Mesh deployment\n\nFor backwards compatibility, the Helm charts default to Mesh being disabled. To\nenable it, you will need to configure the service under `bitbucket:` stanza in\nthe `values.yaml` file, substituting the values below from the above steps where\nappropriate:\n\n```yaml\nimage:\n tag: \n\nbitbucket:\n mesh:\n enabled: true\n image:\n version: \n```\n\n### Adding the Mesh nodes to Bitbucket\n\nTo enable the deployed Mesh nodes you need to add them to the Bitbucket Data\nCenter instance in the administration area. To do so, you'll need the\nservice URL of each node; these are usually of the form `bitbucket-mesh-`. Check the Kubernetes\nofficial documentation to learn how to get a [DNS record for a service](https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/#services){.external}.\n\nTo connect the Mesh node:\n\n1. In your Bitbucket Data Center instance, navigate to **Administration** > **Git** > **Bitbucket Mesh**.\n1. Enter the URL of the Mesh node in the Node URL field (e.g. `http://bitbucket-mesh-1:7777`).\n1. (Optional) Enter a name for the Mesh node in the Node name field.\n1. Select **Add Mesh node**.\n\n[Learn more details about Mesh configuration](https://confluence.atlassian.com/bitbucketserver/set-up-and-configure-mesh-nodes-1128304356.html#SetupandconfigureMeshnodes-ConnectingtheMeshnodetoBitbucket).\n\n### Migrating existing repositories to Mesh\n\n[Learn how to migrate repositories to Mesh](https://confluence.atlassian.com/bitbucketserver/migrate-repositories-to-bitbucket-mesh-1128304358.html).\n" }, { "path": "docs/docs/examples/bitbucket/BITBUCKET_MIRRORS.md", "content": "# Smart Mirroring\n\nSmart Mirroring can greatly improve Git clone speeds for distributed teams working with large repositories. Large repositories that take hours to clone from a Bitbucket instance over the Internet from the other side of the world can take minutes when cloned from a local mirror on a fast network.\n\n![smart mirrors](../../assets/images/bitbucket_mirrors/smart_mirrors_diagram.png)\n\nYou can learn more details about smart mirroring on the [official documentation page](https://confluence.atlassian.com/bitbucketserver/smart-mirroring-776640046.html).\n\n!!!tip \"Upstream/Primary instance\"\n **Primary instance** is sometimes called **upstream** instance.\n\n\n## Requirements\n\n!!!warning \"Primary instance prerequisites\"\n \n **Your primary Bitbucket instance must be a fully licensed Bitbucket Data Center instance**\n \n You do not have to run your Bitbucket Data Center instance as a multi-node cluster to use smart mirroring, but you must have an up-to-date Data Center license.\n\n **The primary instance and all mirror(s) must have HTTPS with a valid (i.e., signed by a Certificate Authority anchored to the root and not expired) SSL certificate**\n \n This is a strict requirement of smart mirroring on both the primary instance and all mirror(s), and cannot be bypassed. The mirror setup wizard will not proceed if either the mirror or the primary instance does not have a valid SSL certificate.\n\n **The primary Bitbucket instance must have SSH enabled**\n \n Mirrors keep their repositories synchronized with the primary instance over SSH and cannot use HTTP or HTTPS for this. See Enable SSH access to Git repositories for instructions on enabling SSH access on your primary instance.\n\n\n## Installation\n\n### Overview\n\n1. Install the **primary** as usual with Bitbucket Helm chart.\n * You need to make sure the instance complies with all the above listed requirements.\n2. Install the **mirror** with second Bitbucket Helm chart.\n * There is a set of properties that need to be configured to make the mirror work.\n3. Approve the **mirror** in the **primary** instance.\n\n### Steps\n\n#### Mirror Farm installation in Kubernetes\n\n!!!info Ingress configuration\n \n Example is using [nginx-ingress controller](../ingress/INGRESS_NGINX.md). If you are using a different ingress controller, you will need to modify the example.\n\n1. Install the **primary** as usual with Bitbucket Helm chart.\n * You need to make sure the instance complies with all the above listed requirements.\n * Verify that you are able to clone from the primary via SSH protocol.\n * Verify that primary instance is accessible over HTTPS with a valid SSL certificate.\n2. Create a new file `values-mirror.yaml` with the following content:\n``` yaml\nbitbucket:\n mode: mirror\n displayName: Bitbucket Mirror\n clustering:\n enabled: true\n applicationMode: \"mirror\"\n mirror:\n upstreamUrl: # for example https://bitbucket-upstream.example.com\n\n# nginx specific configuration\ningress:\n create: true\n host: bitbucket-mirror.example.com\n annotations:\n cert-manager.io/issuer: \"letsencrypt-prod\" # Default issuer\n tlsSecretName: # E.g. tls-certificate-mirror\n\n# enables persistence for mirror data\nvolumes:\n localHome:\n persistentVolumeClaim:\n create: true\n```\n3. Edit the file to change the placeholder values.\n * `bitbucket.mirror.upstreamUrl`\n * `ingress.host`\n * `ingress.tlsSecretName`\n4. Install the mirror\n ``` shell\n helm install bitbucket-mirror atlassian-data-center/bitbucket -f values-mirror.yaml\n ```\n\n#### Mirror farm authorization\n\nThese steps are described in detail in [official documentation](https://confluence.atlassian.com/bitbucketserver/set-up-and-configure-a-mirror-farm-978205589.html#Setupandconfigureamirrorfarm-4.Approvethemirrorfarmrequest).\n\n1. Visit the mirror URL (it might take a couple of minutes to come up)\n2. Click on *Go to the primary server* in the mirror UI. The link will take you to the administration section of the primary instance.
\n ![mirror_setup](../../assets/images/bitbucket_mirrors/mirror_authorize.png){ width=\"400\" }\n3. Click *Authorize* next to the mirror
\n ![click_authorize](../../assets/images/bitbucket_mirrors/upstream_authorize.png)\n4. Select which projects should be synchronized
\n ![select_projects](../../assets/images/bitbucket_mirrors/select_projects_to_mirror.png)\n5. Wait for the projects to be synchronized
\n ![project_synchronized](../../assets/images/bitbucket_mirrors/mirror_synchronized.png)\n6. Verify that the synchronized projects can be cloned from the mirror
\n ![clone_from_mirror](../../assets/images/bitbucket_mirrors/clone_from_mirror.png){ width=\"400\"}\n\n## Scaling the mirror farm\n\nAs the mirror is deployed with all the fulfilled requirements for the Bitbucket Mirror Farm, you are able to scale the mirrors easily. To increase or decrease the size of the mirror farm:\n\n``` shell\nhelm upgrade --set replicaCount= \\\n --reuse-values \\\n \n atlassian-data-center/bitbucket\n```\n\n## Adding or removing additional mirror farms\n\nIt is possible to connect multiple mirror farms to a single primary instance. This can be useful to improve local performance for geographically distributed teams.\n\n*To add a new mirror farm*, follow the same steps that were necessary to connect the first mirror farm. This means installing another helm release and authenticating it in the administrator user interface.\n\n*To remove a mirror farm*:\n\n1. Navigate to *Mirrors* administration section on the **primary**\n2. Select the mirror from the list\n3. Click *Delete* button\n4. Uninstall the deleted mirror helm release from the cluster\n\n## Troubleshooting\n\nYou can find the most common errors in mirror configuration described in the [official Bitbucket documentation](https://confluence.atlassian.com/bitbucketserverkb/troubleshooting-smart-mirroring-838407670.html)." }, { "path": "docs/docs/examples/bitbucket/BITBUCKET_OPENSEARCH.md", "content": "!!!info \"Helm chart version\"\n OpenSearch sub-chart is supported in Bitbucket Helm chart version 1.20 onwards.\n\n## Deploy OpenSearch Helm chart with Bitbucket\n\n!!!warning \"Support disclaimer\"\n Atlassian does not officially support OpenSearch Helm chart that can be installed with the Bitbucket Helm release. Should you encounter any issues with the deployment, maintenance and upgrades, reach out to the [vendor](https://github.com/opensearch-project/helm-charts/tree/main/charts/opensearch){.external}.\n Moreover, if you intend to deploy OpenSearch to a critical Kubernetes environment, make sure you follow all the best practices, i.e. deploy a multi node cluster, use taints and tolerations, affinity rules, sufficient resources requests, have DR and backup strategies etc.\n\nTo deploy OpenSearch Helm chart and automatically configure Bitbucket to use it as a search platform, set the following in your Helm values file:\n\n```yaml\nopensearch:\n install: true\n```\nThis will:\n\n* auto-generate the initial OpenSearch admin password and create a Kubernetes secret with `OPENSEARCH_INITIAL_ADMIN_PASSWORD` key\n* deploy [OpenSearch Helm chart](https://github.com/opensearch-project/helm-charts/tree/main/charts/opensearch){.external} to the target namespace with the default settings: single node, no SSL, 1Gi memory/1 vCPU resources requests, 10Gi storage request\n* set `PLUGIN_SEARCH_CONFIG_BASEURL` to `http://opensearch-cluster-master:9200` unless overridden in `opensearch.baseUrl`\n* set `PLUGIN_SEARCH_CONFIG_USERNAME` to `admin` (this is the initial admin user created when the OpenSearch cluster starts for the very first time)\n* set `PLUGIN_SEARCH_CONFIG_PASSWORD` to a randomly generated password saved to `opensearch-initial-password` secret\n\n## Create dedicated OpenSearch user\n\nWhen the Helm chart is installed with the default values, OpenSearch admin user is created with an auto-generated password, and Bitbucket is configured to use these credentials to connect to OpenSearch. If you want to have a more fine-grained control over internal users, you may pre-create a secret with a list of users, their credentials and roles. See [internal_users.yml](https://opensearch.org/docs/latest/security/configuration/yaml/#internal_usersyml){.external} for more details.\n\n### Hash passwords\n\nPasswords in `internal_users.yml` must be hashed. You can use `hash.sh` script bundled with Bitbucket to hash your passwords, for example:\n\n```shell\ndocker run atlassian/bitbucket:latest /bin/bash -c \"chmod +x /opt/atlassian/bitbucket/opensearch/plugins/opensearch-security/tools/hash.sh && /opt/atlassian/bitbucket/opensearch/plugins/opensearch-security/tools/hash.sh -p mySecureAdminPassword123\"\n\n$2y$12$bcUjaXcfutyYwkjp6r/RdePrywC3BmQLKvN77XuuR0PJs0qjBooSv\n```\nIf Bitbucket is already up and running in your Kubernetes cluster, you can run exec into the Bitbucket container to hash a password:\n\n```shell\nkubectl exec -ti bitbucket-0 -n atlassian -- /bin/bash -c \"chmod +x /opt/atlassian/bitbucket/opensearch/plugins/opensearch-security/tools/hash.sh && /opt/atlassian/bitbucket/opensearch/plugins/opensearch-security/tools/hash.sh -p mySecureBitbucketPassword123\"\n\n$2y$12$x910YF09tcfhNs009vOzWOMy9fswhpsuV5/AiiPwbY4rp5BXKv2tv\n```\n\n### Create internal_users.yml file\n\nThis is the minimal `internal_users.yml` file with an admin and a dedicated bitbucket user. See [internal_users.yml](https://opensearch.org/docs/latest/security/configuration/yaml/#internal_usersyml){.external} to get more details about users, roles and role mappings in OpenSearch.\n\n```yaml\n_meta:\n type: \"internalusers\"\n config_version: 2\n\nadmin:\n hash: \"$2y$12$bcUjaXcfutyYwkjp6r/RdePrywC3BmQLKvN77XuuR0PJs0qjBooSi\"\n reserved: true\n backend_roles:\n - \"admin\"\n description: \"Demo admin user\"\n\nbitbucket:\n hash: \"$2y$12$x910YF09tcfhNs009vOzWOMy9fswhpsuV5/AiiPwbY4rp5BXKv2tu\"\n reserved: true\n backend_roles:\n - \"admin\"\n description: \"Bitbucket admin user\"\n```\n\n### Create Kubernetes secret\n\nCreate a Kubernetes secret with 3 keys in its data:\n\n!!!warning \"internal_users.yml\"\n Make sure there are no typos in `internal_users.yml` filename, otherwise OpenSearch pods can't be created due to a missing key in the secret.\n\n```shell\nkubectl create secret generic opensearch-internal-users \\\n --from-literal=username=bitbucket \\\n --from-literal=password=\"mySecureBitbucketPassword123\" \\\n --from-file=internal_users.yml=/path/to/internal_users.yml \\\n -n atlassian\n```\n\n### Update Helm values\n\nNow that the secret has been created, update your Helm values to point OpenSearch and Bitbucket to `opensearch-internal-users` secret:\n\n```yaml\nopensearch:\n install: true\n credentials:\n secretName: opensearch-internal-users\n usernameSecretKey: username\n passwordSecretKey: password\n securityConfig:\n internalUsersSecret: opensearch-internal-users\n```\n\nIf necessary, you can create 2 separate secrets - one for the `internal_users.yml` only, and one with the actual non-hashed OpenSearch credentials that Bitbucket will use.\n\n## Override OpenSearch Helm chart values\n\nYou can configure your OpenSearch cluster and the deployment options by overriding any values that the [Helm chart](https://github.com/opensearch-project/helm-charts/blob/main/charts/opensearch/values.yaml){.external} exposes. OpenSearch values must be nested under `opensearch` stanza in your Helm values file, for example:\n\n```yaml\nopensearch:\n singleNode: false\n replicas: 5\n config:\n opensearch.yml: |\n cluster.name: custom-cluster\n```\n\n## Enable SSL with Custom Certificates \n\nBy default, OpenSearch starts with the SSL http plugin disabled, meaning the cluster is accessible via HTTP at http://opensearch-cluster-master:9200. The OpenSearch service is not exposed through a LoadBalancer or Ingress unless the default configurations are explicitly overridden. Bitbucket communicates with the OpenSearch cluster using the service name within the internal Kubernetes network. This setup uses the Kubernetes DNS to resolve the service name to the appropriate cluster IP address.\n\nTo enable SSL in OpenSearch and start the service on a secure port, you need to:\n* Enable SSL HTTPS in Helm values.\n* Create Kubernetes secrets with `ca`, `certificate` and `key`, and pass them to OpenSearch.\n* Add `ca.crt` to Java trust store in Bitbucket containers if the custom certificate is not signed by a public authority.\n\nBelow is an **example** (not the recommended way) of how to generate a CA certificate, a server certificate, and a corresponding private key for securing communications with OpenSearch:\n\n```shell\nopenssl req -new -newkey rsa:2048 -days 365 -nodes -x509 -subj \"/C=US/ST=CA/L=LA/O=MyCompany Name/CN=opensearch-cluster-master\" -keyout ca.key -out ca.crt\nopenssl req -new -newkey rsa:2048 -nodes -keyout opensearch-cluster-master.key -subj \"/C=US/ST=CA/L=LA/O=MyCompany Name/CN=opensearch-cluster-master\" -out opensearch-cluster-master.csr\nopenssl x509 -req -days 365 -in opensearch-cluster-master.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out opensearch-cluster-master.crt\n```\n\nIt is important to generate the certificate for `opensearch-cluster-master` CN because this is the actual OpenSearch service/host name in the target namespace.\n\nOnce done, create 3 Kubernetes secrets:\n\n```shell\nkubectl create secret generic opensearch-ssl-ca -n atlassian --from-file=root-ca.pem=ca.crt\nkubectl create secret generic opensearch-ssl-key -n atlassian --from-file=esnode-key.pem=opensearch-cluster-master.key\nkubectl create secret generic opensearch-ssl-cert -n atlassian --from-file=esnode.pem=opensearch-cluster-master.crt\n```\n\nEnable ssl http plugin, override the default ca, certificate and key, as well as provide additional volume mounts in Bitbucket Helm values file:\n\n```yaml\nopensearch:\n extraEnvs:\n - name: plugins.security.ssl.http.enabled\n value: \"true\"\n - name: plugins.security.ssl.transport.pemkey_filepath\n value: \"esnode-key.pem\"\n - name: plugins.security.ssl.transport.pemcert_filepath\n value: \"esnode.pem\"\n - name: plugins.security.ssl.transport.pemtrustedcas_filepath\n value: \"root-ca.pem\"\n secretMounts:\n - name: opensearch-ssl-cert\n secretName: opensearch-ssl-cert\n path: /usr/share/opensearch/config/esnode.pem\n subPath: esnode.pem\n - name: opensearch-ssl-key\n secretName: opensearch-ssl-key\n path: /usr/share/opensearch/config/esnode-key.pem\n subPath: esnode-key.pem\n - name: opensearch-ssl-ca\n secretName: opensearch-ssl-ca\n path: /usr/share/opensearch/config/root-ca.pem\n subPath: root-ca.pem\n```\nWhen using a self-signed certificate or a certificate not issued/signed by a recognized public certificate authority (CA), it is essential to add the CA certificate to the Java trust store in all Bitbucket containers:\n\n```yaml\nbitbucket:\n additionalCertificates:\n secretName: opensearch-ssl-ca\n```\n\nAdditionally, you need to update the protocol specified in the baseUrl to HTTPS:\n\n```yaml\nbitbucket:\n additionalCertificates:\n secretName: opensearch-ssl-ca\nopensearch:\n baseUrl: https://opensearch-cluster-master:9200\n```\n\n## Enable Ingress\n\nTo communicate with the OpenSearch cluster through a fully qualified domain name rather than via Kubernetes internal DNS name, you can enable an Ingress in the OpenSearch Helm chart. Below is an example of how to configure Ingress and update base URL in the Helm values file:\n\n\n```yaml\nopensearch:\n baseUrl: https://myopensearch.com\n ingress:\n install: true\n```\nImportant considerations:\n\n* Ensure that the `baseUrl` is set to use HTTPS protocol, which encrypts the data exchanged with the OpenSearch cluster\n* Ensure that the Ingress hostname can be resolved from within the Kubernetes cluster network\n* If the certificate is not signed by a public authority, you will need to add the certificate to Java trust store in Bitbucket containers by defining a secret name in `bitbucket.additionalCertificates.secretName`\n\n## Use AWS OpenSearch Service\n\nIf you're using AWS OpenSearch Service (managed service) instead of deploying your own OpenSearch cluster, configure Bitbucket to connect to your existing AWS OpenSearch domain using environment variables.\n\n### Prerequisites\n\n* Create an AWS OpenSearch Service domain\n* Configure domain access policy to allow your EKS cluster\n* Have the domain endpoint URL and credentials ready\n\n### Configuration\n\n```yaml\nbitbucket:\n clustering:\n enabled: true\n # Do not enable the opensearch helm chart\n opensearch:\n enabled: false\n \n additionalEnvironmentVariables:\n - name: SEARCH_ENABLED\n value: \"false\"\n - name: PLUGIN_SEARCH_CONFIG_BASEURL\n value: \"https://search-your-domain-abc123.us-east-1.es.amazonaws.com\"\n - name: PLUGIN_SEARCH_CONFIG_USERNAME\n valueFrom:\n secretKeyRef:\n name: aws-opensearch-credentials\n key: username\n - name: PLUGIN_SEARCH_CONFIG_PASSWORD\n valueFrom:\n secretKeyRef:\n name: aws-opensearch-credentials\n key: password\n```\n\n### Create AWS OpenSearch Credentials Secret\n\n```shell\nkubectl create secret generic aws-opensearch-credentials \\\n --from-literal=username=your-master-username \\\n --from-literal=password=your-master-password \\\n -n your-namespace\n```\n\n### Using IAM Authentication\n\nFor domains using IAM authentication, configure IAM roles and omit username/password:\n\n```yaml\nbitbucket:\n clustering:\n enabled: true\n opensearch:\n enabled: false\n \n additionalEnvironmentVariables:\n - name: SEARCH_ENABLED\n value: \"false\"\n - name: PLUGIN_SEARCH_CONFIG_BASEURL\n value: \"https://search-your-domain-abc123.us-east-1.es.amazonaws.com\"\n # No username/password needed - uses IAM role\n```\n\n## Troubleshooting\n\n### Authentication\n\nIf you run into auth issues (401 response from OpenSearch), check the following:\n\n* exec into the Bitbucket container and run:\n ```shell\n curl -v -u ${PLUGIN_SEARCH_CONFIG_USERNAME}:${PLUGIN_SEARCH_CONFIG_PASSWORD} http://opensearch-cluster-master:9200/_cat/indices?v\n ```\n If you get 401, then the user or password passed to the Bitbucket container does not match user or password defined in the `internal_users.yml`\n\n* you can find out where the actual values of `PLUGIN_SEARCH_CONFIG_USERNAME` and `PLUGIN_SEARCH_CONFIG_PASSWORD` environment variables come from by running:\n\n ```shell\n kubectl get pod bitbucket-0 -n atlassian -o jsonpath=\"{.spec.containers[0].env[?(@.name=='PLUGIN_SEARCH_CONFIG_USERNAME')]}\"\n kubectl get pod bitbucket-0 -n atlassian -o jsonpath=\"{.spec.containers[0].env[?(@.name=='PLUGIN_SEARCH_CONFIG_PASSWORD')]}\"\n ```\n* Make sure that hashed password of the bitbucket user in the `internal_users.yml` file corresponds to the plain text password stored in the Kubernetes secret.\n\n### Networking\n\nThe default `opensearch-cluster-master` hostname must be resolved to a Kubernetes service cluster IP, and the request is then forwarded directly to the pod endpoint.\nIf you see connection refused/timeout errors, make sure all OpenSearch pods are in a Ready state and the corresponding endpoints have been created:\n\n```shell\nkubectl describe pod -n atlassian -l=app.kubernetes.io/component=opensearch-cluster-master\n```\n\n```shell\nkubectl get endpoints -n atlassian\n\nNAME ENDPOINTS AGE\nbitbucket 10.0.2.31:7999,10.0.2.31:7990,10.0.2.31:5701 113m\nopensearch-cluster-master 10.0.1.170:9200,10.0.1.170:9300 113m\nopensearch-cluster-master-headless 10.0.1.170:9600,10.0.1.170:9200,10.0.1.170:9300 113m\n```" }, { "path": "docs/docs/examples/bitbucket/BITBUCKET_SESSION_AFFINITY.md", "content": "# Configure Session Stickiness with NGINX Ingress\n\n## Default Configuration\n\n```yaml\ningress:\n create: true\n nginx: true # Enables session stickiness automatically\n host: bitbucket.example.com\n\nbitbucket:\n clustering:\n enabled: true\n```\n\n## Custom Configuration\n\n```yaml\ningress:\n create: true\n nginx: true\n host: bitbucket.example.com\n annotations:\n \"nginx.ingress.kubernetes.io/session-cookie-name\": \"BITBUCKET-SESSION\"\n \"nginx.ingress.kubernetes.io/session-cookie-max-age\": \"28800\" # 8 hours\n```\n\n## Verifying Session Stickiness\n\nTest that session stickiness is working:\n\n```shell\n# Check ingress annotations\nkubectl describe ingress bitbucket -n atlassian\n\n# Test with curl (look for Set-Cookie header)\ncurl -I https://bitbucket.example.com/status\n```\n\n## Troubleshooting\n\nIf users are experiencing random logouts or Git operation failures:\n\n1. **Verify NGINX annotations are applied**:\n ```shell\n kubectl get ingress bitbucket -n atlassian -o yaml\n ```\n\n2. **Check if requests hit the same pod**:\n ```shell\n kubectl logs -f -l app.kubernetes.io/name=bitbucket -n atlassian\n ```\n\n3. **Ensure clustering is enabled**:\n ```yaml\n bitbucket:\n clustering:\n enabled: true\n ```\n\n!!!tip \"Production recommendation\"\n Set `session-cookie-max-age` to match your typical user session duration (e.g., 8 hours = 28800 seconds) to balance user experience with security. " }, { "path": "docs/docs/examples/bitbucket/BITBUCKET_SSH.md", "content": "# SSH service in Bitbucket on Kubernetes\n\nIn addition to providing a service on HTTP(S), Bitbucket also allows remote Git operations over SSH connections. By default, Kubernetes Ingress controllers only work for HTTP connections, but some ingress controllers also support TCP connections.\n\nDepending on the need of your deployment, SSH access can be provided through three mechanisms:\n\n1. Opening the TCP port through the ingress controller - This option should be used if the SSH service is required to be available on the same DNS name as the HTTP service.\n2. Creating a separate Kubernetes `LoadBalancer` service - This option is available if the ingress controller does not support TCP connections, or if you don’t need your deployment to have the SSH service available on the same DNS name as the HTTP service.\n3. Exposing Bitbucket service as `LoadBalancer` and setting the desired ssh port (defaults to `7999`)\n\n## NGINX Ingress controller config for SSH connections\nWe can follow the official documentation for the NGINX Ingress controller for this: [Exposing TCP and UDP services - NGINX Ingress Controller](https://kubernetes.github.io/ingress-nginx/user-guide/exposing-tcp-udp-services/){.external}.\n\n!!!info \"Namespace co-location\"\n These instructions should be performed in the same namespace in which the Ingress controller resides.\n\n### 1. Create ConfigMap\nCreate a new `ConfigMap`:\n``` shell\nkubectl create configmap tcp-services\n```\n\nIn our example we deployed Bitbucket using the Helm release name `bitbucket` in the namespace `ssh-test`, update the `ConfigMap` `tcp-services` accordingly:\n\n```yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n name: tcp-services\n namespace: ingress-nginx\ndata:\n 7999: \"/:ssh\"\n```\n\n### 2. Update Ingress deployment\nNext, we have to edit the `deployment` of the ingress controller and add the `--tcp-services-configmap` option:\n```shell\nkubectl edit deployment \n```\nAdd this line in the `args` of the container `spec`:\n```shell\n- --tcp-services-configmap=$(POD_NAMESPACE)/tcp-services\n```\nso it looks something like this:\n```yaml\n spec:\n containers:\n - args:\n - /nginx-ingress-controller\n - --publish-service=$(POD_NAMESPACE)/ingress-nginx-controller\n - --election-id=ingress-controller-leader\n - --ingress-class=nginx\n - --configmap=$(POD_NAMESPACE)/ingress-nginx-controller\n - --validating-webhook=:8443\n - --validating-webhook-certificate=/usr/local/certificates/cert\n - --validating-webhook-key=/usr/local/certificates/key\n - --tcp-services-configmap=$(POD_NAMESPACE)/tcp-services\n```\n\n### 3. Update the Ingress service\nUpdate the Ingress service to include an additional `port` definition for `ssh`\n```shell\nkubectl edit service \n```\nAdd this section in the `ports` of the container `spec`:\n```yaml\n- name: ssh\n port: 7999\n protocol: TCP\n```\nso it looks something like this:\n```yaml\nspec:\n clusterIP: 10.100.19.60\n externalTrafficPolicy: Cluster\n ports:\n - name: http\n nodePort: 31381\n port: 80\n protocol: TCP\n targetPort: http\n - name: https\n nodePort: 32612\n port: 443\n protocol: TCP\n targetPort: https\n - name: ssh\n port: 7999\n protocol: TCP\n```\nAfter the deployment has been upgraded, the `SSH` service should be available on port `7999`.\n\n## LoadBalancer service for SSH connections on AWS\nIn the values file for the helm chart, the extra SSH service can be enabled like this:\n```yaml\nbitbucket:\n sshService:\n enabled: true\n```\nOn a deployment using AWS, assuming you have [external-dns](https://github.com/kubernetes-sigs/external-dns){.external} configured, you can add these annotations to automatically set up the DNS name for the SSH service:\n```yaml\nbitbucket:\n sshService:\n enabled: true\n annotations:\n external-dns.alpha.kubernetes.io/hostname: bitbucket-ssh.example.com\n additionalEnvironmentVariables:\n - name: PLUGIN_SSH_BASEURL\n value: ssh://bitbucket-ssh.example.com/\n```\n## Expose Bitbucket Service as a LoadBalancer\n\nThis method implies creation of one K8S service of a `LoadBalancer` type. A cloud provider (e.g. AWS) will create listeners for each port declared in the service. Here's an example of exposing Bitbucket service in EKS, using a Classic LoadBalancer and dynamically provisioning DNS entries with [external-dns](https://github.com/kubernetes-sigs/external-dns){.external}:\n\n```yaml\nbitbucket:\n service:\n port: 443\n sshPort: 22\n type: LoadBalancer\n annotations:\n external-dns.alpha.kubernetes.io/hostname: bitbucket.example.com\n service.beta.kubernetes.io/aws-load-balancer-ssl-ports: \"443\"\n service.beta.kubernetes.io/aws-load-balancer-ssl-cert: arn:aws:acm:us-east-1:111111111111:certificate/8xy4ny81-0a4w-8caq-a524-1101cv3v4vwb\n additionalEnvironmentVariables:\n - name: PLUGIN_SSH_BASEURL\n value: ssh://bitbucket.example.com\ningress:\n host: bitbucket.example.com\n```\n\nThe above service annotations are specific to the Classic LoadBalancer, however, you can provide [NLB](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/introduction.html){.external} specific [annotations](https://kubernetes-sigs.github.io/aws-load-balancer-controller/v2.2/guide/service/annotations/){.external} as well.\n\nThe default `bitbucket.service.sshPort` is set to `22` so that AWS can create a listener for this port, and as a result your ssh git URL will look like `ssh://bitbucket.example.com/project/repo`. \n\n!!!info \"Ingress host\"\n\n Even though `ingress` is disabled, `ingress.host` needs to be set because it is used in a few conditions in the StatefulSet template.\n" }, { "path": "docs/docs/examples/cluster/AKS_SETUP.md", "content": "# Preparing an AKS cluster\nThis example provides instructions for creating a Kubernetes cluster using [Azure AKS](https://azure.microsoft.com/en-au/services/kubernetes-service/){.external}.\n\n## Prerequisites\nWe recommend installing and configuring the [Azure Cloud Shell](https://docs.microsoft.com/en-au/azure/cloud-shell/quickstart){.external}, allowing for CLI interaction with the AKS cluster.\n\n## Manual creation\nFollow the [Azure Kubernetes Service Quickstart](https://docs.microsoft.com/en-au/azure/aks/kubernetes-walkthrough){.external} for details on creating an AKS cluster.\n\n---\n!!!tip \"Next step - Ingress controller\"\n\n Having established a cluster, continue with provisioning the next piece of prerequisite infrastructure, the [Ingress controller](../../userguide/PREREQUISITES.md#provision-an-ingress-controller)." }, { "path": "docs/docs/examples/cluster/CLOUD_PROVIDERS.md", "content": "# Provisioning Kubernetes clusters on cloud-based providers\n\nHere are installation and configuration instructions for cloud providers:\n\n* [Amazon EKS](EKS_SETUP.md) \n* [Google GKE](GKE_SETUP.md)\n* [Azure AKS](AKS_SETUP.md)\n" }, { "path": "docs/docs/examples/cluster/EKS_SETUP.md", "content": "# Preparing an EKS cluster\nThis example provides instructions for creating a Kubernetes cluster using [Amazon EKS](https://aws.amazon.com/eks/){.external}.\n\n## Prerequisites\nWe recommend installing and configuring [eksctl](https://docs.aws.amazon.com/eks/latest/userguide/eksctl.html){.external}, allowing for CLI interaction with the EKS cluster.\n\n## Manual creation\nFollow the [Getting started with Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/getting-started.html){.external} for details on creating an EKS cluster. Or, using the `ClusterConfig` below as an example, deploy a K8s cluster with `eksctl` in ~20 minutes:\n\n```yaml\napiVersion: eksctl.io/v1alpha5\nkind: ClusterConfig\n\nmetadata:\n name: atlassian-cluster\n region: ap-southeast-2\n\nmanagedNodeGroups:\n - name: appNodes\n instanceType: m5.large\n desiredCapacity: 2\n ssh: # enable SSH using SSM\n enableSsm: true\n```\n\n???question \"Cluster considerations\"\n It's always a good idea to consider the following points before creating the cluster:\n\n 1. [Geographical region](https://aws.amazon.com/about-aws/global-infrastructure/regions_az/){.external} - where will the cluster reside.\n 2. [EC2 instance type](https://aws.amazon.com/ec2/instance-types/){.external} - the instance type to be used for the nodes that make up the cluster.\n 3. Number of nodes - guidance on the resource dimensions that should be used for these nodes can be found in [Requests and limits](../../userguide/resource_management/REQUESTS_AND_LIMITS.md).\n\nAdding the config above to a file named `config.yaml` provision the cluster: \n\n```shell\neksctl create cluster -f config.yaml\n```\n\n---\n!!!tip \"Next step - Ingress controller\"\n \n Having established a cluster, continue with provisioning the next piece of prerequisite infrastructure, the [Ingress controller](../../userguide/PREREQUISITES.md#provision-an-ingress-controller).\n" }, { "path": "docs/docs/examples/cluster/GKE_SETUP.md", "content": "# Preparing an GKE cluster\nThis example provides instructions for creating a Kubernetes cluster using [Google GKE](https://cloud.google.com/kubernetes-engine){.external}.\n\n## Prerequisites\nWe recommend installing and configuring [Google Cloud SDK](https://cloud.google.com/sdk/docs/install){.external}, allowing for CLI interaction with an GKE cluster.\n\n## Manual creation\nFollow the [How-to guides](https://cloud.google.com/kubernetes-engine/docs/how-to#creating-clusters){.external} for details on creating an GKE cluster. \n\n---\n!!!tip \"Next step - Ingress controller\"\n\n Having established a cluster, continue with provisioning the next piece of prerequisite infrastructure, the [Ingress controller](../../userguide/PREREQUISITES.md#provision-an-ingress-controller)." }, { "path": "docs/docs/examples/confluence/.pages", "content": "collapse_single_pages: false\nnav:\n - CONFLUENCE_OPENSEARCH.md\n - ...\n" }, { "path": "docs/docs/examples/confluence/CONFLUENCE_OPENSEARCH.md", "content": "# Configuring OpenSearch for Confluence\n\n!!!info \"Confluence and Helm chart version\"\n OpenSearch is supported in Confluence 8.9.0 and Helm chart 1.19 onwards.\n\nAs Confluence instances grow in size and scale, the default search engine, Lucene, may be slower to index and return search results. To address this, Confluence Data Center offers an alternative search engine as an opt-in feature — OpenSearch.\n\nFind more information on advantages of using OpenSearch in the [official documentation](https://confluence.atlassian.com/doc/configuring-opensearch-for-confluence-1387594125.html){.external}\n\n## Deploy OpenSearch Helm Chart with Confluence\n\n!!!warning \"Support disclaimer\"\n Atlassian does not officially support OpenSearch Helm chart that can be installed with the Confluence Helm release. Should you encounter any issues with the deployment, maintenance and upgrades, reach out to the [vendor](https://github.com/opensearch-project/helm-charts/tree/main/charts/opensearch){.external}.\n Moreover, if you intend to deploy OpenSearch to a critical Kubernetes environment, make sure you follow all the best practices, i.e. deploy a multi node cluster, use taints and tolerations, affinity rules, sufficient resources requests, have DR and backup strategies etc. \n\n## Deploy with the default settings\n\nTo deploy OpenSearch Helm chart and automatically configure Confluence to use it as a search platform, set the following in your Helm values file:\n\n```yaml\nopensearch:\n enabled: true\n```\nThis will:\n\n* auto-generate the initial OpenSearch admin password and create a Kubernetes secret with `OPENSEARCH_INITIAL_ADMIN_PASSWORD` key\n* deploy [OpenSearch Helm chart](https://github.com/opensearch-project/helm-charts/tree/main/charts/opensearch){.external} to the target namespace with the default settings: single node, 1Gi memory/1 vCPU resources requests, 10Gi storage request\n* configure Confluence to use the deployed OpenSearch cluster by adding `-Dsearch.platform=opensearch -Dopensearch.http.url=http://opensearch-cluster-master:9200 -Dopensearch.username=admin -Dopensearch.password=yourPassword` to the [JVM ConfigMap](https://github.com/atlassian/data-center-helm-charts/blob/main/src/main/charts/confluence/templates/config-jvm.yaml){.external}\n\n## Override OpenSearch Helm chart values\n\nYou can configure your OpenSearch cluster and the deployment options by overriding any values that the [Helm chart](https://github.com/opensearch-project/helm-charts/blob/main/charts/opensearch/values.yaml){.external} exposes. OpenSearch values must be nested under `opensearch` stanza in your Helm values file, for example:\n\n```yaml\nopensearch:\n singleNode: false\n replicas: 5\n config:\n opensearch.yml: |\n cluster.name: opensearch-cluster\n```\n" }, { "path": "docs/docs/examples/database/AMAZON_RDS.md", "content": "# Creating an RDS database instance\nThis example provides instructions for creating an Amazon [RDS DB instance](https://aws.amazon.com/rds/){.external}.\n\n## Prerequisites\n* An `AWS account`, `IAM user`, `VPC` (or [default VPC](https://docs.aws.amazon.com/vpc/latest/userguide/default-vpc.html){.external}) and `security group` are required before an RDS DB instance can be created. See [Setting up for Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_SettingUp.html){.external} for further instructions.\n\n## Database creation\nThere are two steps for creating the database:\n\n1. [Initialize database server](#1-initialize-database-server)\n2. [Initialize database and user](#2-initialize-database-and-user)\n\n### 1. Initialize database server\nFor details on standing up an RDS DB server follow the guide: [Creating an Amazon RDS DB instance](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_CreateDBInstance.html){.external}.\n### 2. Initialize database and user\n!!!danger \"Don't forget to create the database and user!\"\n\n This is a required step. For details on creating the application database and database user follow the appropriate guide below:\n\n=== \"Jira\"\n [Create database for Jira](https://confluence.atlassian.com/adminjiraserver/connecting-jira-applications-to-a-database-938846850.html){.external}\n=== \"Confluence\"\n [Create database for Confluence](https://confluence.atlassian.com/doc/database-configuration-159764.html#DatabaseConfiguration-Databasesetupsetup){.external}\n=== \"Bitbucket\"\n [Create database for Bitbucket](https://confluence.atlassian.com/bitbucketserver/connect-bitbucket-to-an-external-database-776640378.html){.external}\n=== \"Bamboo\"\n [Create database for Bamboo](https://confluence.atlassian.com/bamboo/connecting-bamboo-to-an-external-database-289276815.html){.external}\n=== \"Crowd\"\n [Create database for Crowd](https://confluence.atlassian.com/crowd/connecting-crowd-to-a-database-4030904.html){.external}\n \n---\n!!!tip \"Next step - Shared storage\"\n \n Having created the database continue with provisioning the next piece of prerequisite infrastructure, [shared storage](../../userguide/PREREQUISITES.md#configure-a-shared-home-volume)." }, { "path": "docs/docs/examples/database/CLOUD_PROVIDERS.md", "content": "# Provisioning databases on cloud-based providers\n\n!!!info \"Supported databases\"\n \n Your selected database engine type must be supported by the Data Center product you wish to install:\n\n === \"Jira\"\n \n [Jira supported databases](https://confluence.atlassian.com/adminjiraserver/supported-platforms-938846830.html#Supportedplatforms-Databases){.external}\n\n === \"Confluence\"\n \n [Confluence supported databases](https://confluence.atlassian.com/doc/supported-platforms-207488198.html#SupportedPlatforms-Databases){.external}\n\n === \"Bitbucket\"\n \n [Bitbucket supported databases](https://confluence.atlassian.com/bitbucketserver/supported-platforms-776640981.html#Supportedplatforms-databasesDatabases){.external}\n\n === \"Bamboo\"\n\n [Supported databases](https://confluence.atlassian.com/bamboo/supported-platforms-289276764.html#Supportedplatforms-Databases){.external}\n\n === \"Crowd\"\n \n [Crowd supported databases](https://confluence.atlassian.com/crowd/supported-platforms-191851.html#SupportedPlatforms-Databases){.external}\n\n\nDatabase deployment and configuration instructions for cloud providers can be found below:\n\n* [Amazon RDS](AMAZON_RDS.md)\n" }, { "path": "docs/docs/examples/external_libraries/EXTERNAL_LIBS.md", "content": "# External libraries and plugins\n\n!!!warning \"`.jar` files only\"\n\n Whether loading external libraries, drivers or plugins, the approaches outlined here can only be used with `.jar` files. Plugin `obr` files can be extracted (unzipped) to access the included `.jar`\n\nIn some situations, you may want to load 3rd party plugins, drivers or libraries so that they are available to the product \nbeing installed.\n\nAn example of when this may be needed are for those products that do not ship with the appropriate `MySQL` and `Oracle` \n`JDBC` drivers.\n\nThere are 3 strategies for doing this, you can either:\n\n* [use the required prerequisite shared home volume](#shared-home-volume) \n* [create a custom volume specifically for this purpose](#custom-volume) \n* [provide a custom command for the `nfsPermissionFixer`](#custom-command)\n\nEach approach will be discussed below.\n\n!!!info \"Approach\"\n\n Which approach is used is totally up to you. For convenience you may want to just use [shared-home](../../userguide/PREREQUISITES.md#configure-a-shared-home-volume), or if you'd like to \n keep things clean you may decide to mount these 3rd party libraries in a volume of their own. This approach would be \n particularly useful when these libraries need to be shared with other Pod's in your cluster.\n\n## Shared home volume\nThis approach consists of 3 high-level tasks:\n\n1. Create sub-dir in `shared-home` volume\n2. Copy libraries to sub-dir\n3. Update `additionalLibraries` stanza in `values.yaml`\n\n### 1. Create sub-dir\nAdd the Pod definition below to a file called `shared-home-browser.yaml` \n\n```yaml\napiVersion: v1\nkind: Pod\nmetadata:\n name: shared-home-browser\nspec:\n containers:\n - name: browser\n image: debian:stable-slim\n volumeMounts:\n - mountPath: /shared-home\n name: shared-home\n command: [ \"bash\", \"-c\", \"--\" ]\n args: [ \"while true; do sleep 30; done;\" ]\n volumes:\n - name: shared-home\n persistentVolumeClaim:\n claimName: \n```\nInitialise the Pod in the same namespace in which the `shared-home` PVC was created\n```bash\nkubectl apply -f shared-home-browser.yaml\n```\nOnce running execute the following command, it will create the sub-sir, `libraries`, under `/shared-home`\n```bash\nkubectl exec -it shared-home-browser -- bash -c \"mkdir -p /shared-home/libraries\"\n```\n\n### 2. Copy libraries to sub-dir\nNow copy the files you require to the sub-dir by using the `kubectl cp` command\n```bash\nkubectl cp my_library.jar shared-home-browser:/shared-home/libraries\n```\n\n### 3. Update `values.yaml`\nUpdate the stanza, `additionalLibraries`, in `values.yaml` accordingly:\n```yaml\njira:\n additionalLibraries:\n - volumeName: shared-home\n subDirectory: libraries\n fileName: my_library.jar\n```\nWith this config these files (`my_library.jar`) will be injected into the container directory `/lib`. For more info on how these files are injected into the appropriate product container location, see Jira's helper [jira.additionalLibraries](https://github.com/atlassian/data-center-helm-charts/blob/main/src/main/charts/jira/templates/_helpers.tpl#L180). \n\n## Custom volume\nThis approach is very similar to the [Shared home volume](#shared-home-volume) approach, only a custom volume is created and used as opposed `shared-home`. \n\n1. Create a new volume for storing 3rd party libraries\n2. Create sub-dir for the new volume\n3. Copy libraries to sub-dir\n4. Update `additionalLibraries` stanza in `values.yaml`\n5. Update `additionalVolumeMounts` stanza in `values.yaml`\n6. Update `additional` stanza in `values.yaml`\n\n!!!info \"Steps\"\n\n Because many of the steps for this approach are similar to the steps used for [Shared home volume](#shared-home-volume) only those that differ will be discussed.\n\n### 1. Create new volume\nUsing the same approach taken for provisioning the [shared-home volume](../storage/aws/SHARED_STORAGE.md), create a new `EFS` with a corresponding `PV` and `PVC`.\n\n!!!warning \"ReadOnlyMany\"\n\n Ensure that the PV and PVC are setup with `ReadOnlyMany` access\n\n### 2. Update `values.yaml`\nAssuming that the `PVC` representing the `EFS` is called `third-party-libraries`, update the `values.yaml` so that the `PVC` is added as an `additional` mount:\n```yaml\nvolumes:\n additional:\n - name: third-party-libraries\n persistentVolumeClaim:\n claimName: third-party-libraries\n```\nNow add this as an `additionalVolumeMounts`\n```yaml\nadditionalVolumeMounts:\n - volumeName: third-party-libraries\n mountPath: /libraries\n```\nFinally inject the desired libraries by defining them under `additionalLibraries`\n```yaml\nadditionalLibraries:\n - volumeName: third-party-libraries\n subDirectory: database_drivers\n fileName: my_library.jar\n```\n\n## Custom command\nThis example is based on the GitHub issue discussed [here](https://github.com/atlassian/data-center-helm-charts/issues/239). The `nfsPermissionFixer` in the `values.yaml` is used for appropriately setting the permissions on the `shared-home` volume. The command it uses for this is already defined by default, however\nit can also be supplied with a custom `command` for adding 3rd party libraries to `shared-home`. The example below shows how this approach can be used for adding the `JDBC` `MySQL` driver:\n\n```yaml linenums=\"1\"\nnfsPermissionFixer:\n command: |\n if [[ ! -f /shared-home/drivers/mysql-driver.jar ]]; then\n mkdir -p /shared-home/drivers\n apk add dpkg\n wget https://dev.mysql.com/get/Downloads/Connector-J/mysql-connector-java_8.0.26-1debian10_all.deb\n dpkg-deb -R mysql-connector-java_8.0.26-1debian10_all.deb /tmp/\n cp /tmp/usr/share/java/mysql-connector-java-8.0.26.jar /shared-home/drivers/mysql-driver.jar\n fi\n chgrp 2003 /shared-home; chmod g+w /shared-home\n```\n!!!warning \"shared-home permissions\"\n\n If taking this approach ensure the last thing your custom command does is apply the relevant permissions to the `shared-home` mount, see line `10` in `yaml` \n snippet above. \n\n Each product chart has a `.sharedHome.permissionFix.command` helper for doing this. look at Jira's helper [jira.sharedHome.permissionFix.command](https://github.com/atlassian/data-center-helm-charts/blob/main/src/main/charts/jira/templates/_helpers.tpl#L102) \n for more details on how these permissions are applied by default.\n\nRemember to also update the `additionalLibraries` stanza accordingly:\n```yaml\nadditionalLibraries: \n - volumeName: shared-home\n subDirectory: drivers\n fileName: mysql-driver.jar\n```" }, { "path": "docs/docs/examples/ingress/CONTROLLERS.md", "content": "# Provisioning a traffic entry controller\n\nTo expose an Atlassian DC product outside your Kubernetes cluster, you must run **one** of the following:\n\n- an **Ingress controller** (to process Kubernetes `Ingress` resources), or\n- a **Gateway API controller** (to process Kubernetes Gateway API resources, such as `HTTPRoute`).\n\nThe Helm charts can render either:\n\n- a Kubernetes `Ingress` when `ingress.create: true`, or\n- a Kubernetes Gateway API `HTTPRoute` when `gateway.create: true`.\n\nThese options are **mutually exclusive** (you cannot enable both `ingress.create` and `gateway.create`).\n\n!!!note \"Sticky sessions are required\"\n Atlassian DC products require **session stickiness** (\"sticky sessions\") for high availability. With NGINX Ingress this is handled via controller annotations. With Gateway API you must configure stickiness using your chosen Gateway implementation.\n\n## Example guides\n\n- [NGINX Ingress Controller (Ingress)](INGRESS_NGINX.md)\n- [Gateway API controller (Gateway API)](GATEWAY_API.md)\n" }, { "path": "docs/docs/examples/ingress/DNS.md", "content": "# Create DNS record via AWS CLI\n\n!!!tip \"DNS record creation using Route53\"\n\n The approach below shows how a DNS record can be created using AWS Route53 and the [AWS CLI for record sets](https://aws.amazon.com/premiumsupport/knowledge-center/alias-resource-record-set-route53-cli/){.external}\n\nFirst, identify the name of the auto provisioned [AWS Classic Load Balancer](https://aws.amazon.com/elasticloadbalancing/classic-load-balancer/){.external} that was created above for [Step 2. Install controller](#2-install-controller):\n```shell\nkubectl get service -n ingress | grep ingress-nginx | awk '{print $4}' | head -1\n```\nthe output of this command should be the name of the load balancer, take note of the name i.e.\n```shell\nb834z142d8118406795a34df35e10b17-38927090.eu-west-1.elb.amazonaws.com\n```\nNext, using the first part of the load balancer name, get the `HostedZoneId` for the load balancer\n```shell\naws elb describe-load-balancers --load-balancer-name b834z142d8118406795a34df35e10b17 --region | jq '.LoadBalancerDescriptions[] | .CanonicalHostedZoneNameID'\n```\nWith the `HostedZoneId` and the **full** name of the load balancer create the `JSON` \"change batch\" file below:\n\n```yaml\n{\n \"Comment\": \"An alias resource record for Jira in K8s\",\n \"Changes\": [\n {\n \"Action\": \"CREATE\",\n \"ResourceRecordSet\": {\n \"Name\": ,\n \"Type\": \"A\",\n \"AliasTarget\": {\n \"HostedZoneId\": ,\n \"DNSName\": ,\n \"EvaluateTargetHealth\": true\n }\n }\n }\n ]\n}\n```\n\n!!!tip \"DNS record name\"\n\n If for example, the DNS record name were set to `product.k8s.hoolicorp.com` then the host, `hoolicorp.com`, would be the pre-registerd [AWS Route53 hosted zone](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/route-53-concepts.html#route-53-concepts-hosted-zone){.external}.\n\nNext get the zone ID for the hosted zone:\n```shell\naws route53 list-hosted-zones-by-name | jq '.HostedZones[] | select(.Name == \"hoolicorp.com.\") | .Id'\n```\nFinally, using the hosted zone ID and the `JSON` change batch file created above, initialize the record:\n```shell\naws route53 change-resource-record-sets --hosted-zone-id --change-batch file://change-batch.json\n```\nThis will return a response similar to the one below:\n```json\n{\n \"ChangeInfo\": {\n \"Id\": \"/change/C03268442VMV922ROD1M4\",\n \"Status\": \"PENDING\",\n \"SubmittedAt\": \"2021-08-30T01:42:23.478Z\",\n \"Comment\": \"An alias resource record for Jira in K8s\"\n }\n}\n```\nYou can get the current status of the record's initialization:\n```shell\naws route53 get-change --id /change/C03268442VMV922ROD1M4\n```\nOnce the `Status` has transitioned to `INSYNC` the record is ready for use...\n```json\n{\n \"ChangeInfo\": {\n \"Id\": \"/change/C03268442VMV922ROD1M4\",\n \"Status\": \"INSYNC\",\n \"SubmittedAt\": \"2021-08-30T01:42:23.478Z\",\n \"Comment\": \"Creating Alias resource record sets in Route 53\"\n }\n}\n```" }, { "path": "docs/docs/examples/ingress/GATEWAY_API.md", "content": "# Gateway API controller (HTTPRoute)\n\nThe Atlassian DC Helm charts support exposing products via the **Kubernetes Gateway API** by rendering a `HTTPRoute` resource when `gateway.create: true`.\n\nTo use this, your cluster must have:\n\n- Gateway API CRDs installed\n- a Gateway API controller installed (for example, Envoy Gateway, Istio, etc.)\n- a `Gateway` resource that allows routes from your product namespace\n\n!!!note \"What the charts create\"\n The charts create a **`HTTPRoute`** only. You must provision the **`GatewayClass`**, **`Gateway`**, and (optionally) **TLS certificates** in your cluster.\n\n## 1. Install a Gateway API controller\n\nFollow your chosen implementation's installation instructions:\n\n- Gateway API overview: \n- Implementations: \n\n## 2. Create a Gateway\n\nCreate a `Gateway` that will accept `HTTPRoute` attachments from the namespace where you install the Atlassian product.\n\nThe exact `gatewayClassName`, listener configuration, and TLS configuration depend on your chosen implementation.\n\n## 3. Configure the Helm chart\n\nDisable `ingress.create` and enable `gateway.create`. Provide a **parentRef** pointing to your `Gateway` and at least one **hostname**.\n\n```yaml\ningress:\n create: false\n\ngateway:\n create: true\n hostnames:\n - confluence.example.com\n https: true\n parentRefs:\n - name: atlassian-gateway\n namespace: gateway-system # optional, defaults to release namespace\n sectionName: https # optional, target a specific Gateway listener\n```\n\n!!!info \"TLS termination\"\n With Gateway API, TLS termination is configured on the `Gateway` listeners (not on the `HTTPRoute`). The `gateway.https` value controls the product's proxy/URL settings (e.g., generating HTTPS links), but it does not provision certificates by itself.\n\n## Gateway values reference\n\nThe `gateway` stanza is split into two groups:\n\n**Product configuration** (always active when `gateway.hostnames` is set):\n\n| Value | Description | Default |\n|-------|-------------|---------|\n| `gateway.create` | Create an `HTTPRoute` resource | `false` |\n| `gateway.hostnames` | Hostnames to route; first entry is used as the canonical hostname for base URL and proxy settings | `[]` |\n| `gateway.https` | Whether users access the application over HTTPS | `true` |\n| `gateway.externalPort` | Port users connect on; only set for non-standard ports | `443` (https) / `80` (http) |\n| `gateway.path` | Base path; falls back to `.service.contextPath` when empty | (empty) |\n\n**HTTPRoute configuration** (only applies when `gateway.create: true`):\n\n| Value | Description | Default |\n|-------|-------------|---------|\n| `gateway.parentRefs` | List of [ParentReference](https://gateway-api.sigs.k8s.io/reference/spec/#gateway.networking.k8s.io/v1.ParentReference){.external} objects (`name`, `namespace`, `sectionName`, etc.) | `[]` (required) |\n| `gateway.pathType` | Path matching type: `PathPrefix`, `Exact`, or `RegularExpression` | `PathPrefix` |\n| `gateway.annotations` | Annotations to add to the HTTPRoute | `{}` |\n| `gateway.labels` | Labels to add to the HTTPRoute | `{}` |\n| `gateway.filters` | [HTTPRouteFilter](https://gateway-api.sigs.k8s.io/reference/spec/#gateway.networking.k8s.io/v1.HTTPRouteFilter){.external} list (header modification, redirects, URL rewrites) | `[]` |\n| `gateway.timeouts.request` | Total request timeout | `60s` |\n| `gateway.timeouts.backendRequest` | Backend request timeout | `60s` |\n| `gateway.additionalRules` | Extra [HTTPRouteRule](https://gateway-api.sigs.k8s.io/reference/spec/#gateway.networking.k8s.io/v1.HTTPRouteRule){.external} entries for advanced routing | `[]` |\n\n!!!note \"Using gateway config without creating an HTTPRoute\"\n Setting `gateway.hostnames` activates gateway mode for the product's proxy and base-URL configuration **even when `gateway.create` is false**. This is useful when you have a pre-existing Gateway or external proxy/load balancer and only need the Helm chart to configure the product itself, without creating any Kubernetes routing resource.\n\n## 4. Timeouts\n\nThe `gateway.timeouts` block replaces the Ingress-style `proxyReadTimeout` / `proxySendTimeout` settings:\n\n```yaml\ngateway:\n timeouts:\n request: \"60s\" # total request timeout\n backendRequest: \"60s\" # backend request timeout\n```\n\n!!!warning \"No Gateway API equivalents\"\n There is no standard Gateway API equivalent for `proxyConnectTimeout` or `maxBodySize`. If you need those, configure them through controller-specific policies (e.g. Envoy Gateway `BackendTrafficPolicy`).\n\n\n## Configure session affinity (sticky sessions)\n\nSession affinity is **required** for Atlassian DC products and is **not** part of the standard `HTTPRoute` API.\n\nSee [Session affinity with Gateway API](GATEWAY_API_SESSION_AFFINITY.md) for implementation-specific examples (cookie-based) and links for further reading.\n\n" }, { "path": "docs/docs/examples/ingress/GATEWAY_API_SESSION_AFFINITY.md", "content": "# Session Affinity with Gateway API\n\nAtlassian DC products require **sticky sessions** so that a user is consistently routed to the same pod. With the NGINX Ingress controller this was handled automatically via annotations:\n\n```yaml\nnginx.ingress.kubernetes.io/affinity: \"cookie\"\nnginx.ingress.kubernetes.io/affinity-mode: \"persistent\"\n```\n\nWith Gateway API, session affinity is **not** part of the standard `HTTPRoute` spec and must be configured separately.\n\n## Cookie naming\n\nUse a **dedicated routing cookie** (for example `ATLROUTE_`) rather than the application's own `JSESSIONID`. This avoids conflicts with the application's session cookie and matches the approach used by NGINX Ingress.\n\n## Options at a glance\n\n| Approach | Cookie-based | Standard channel |\n|----------|:---:|:---:|\n| Implementation policy (Option 1) | Yes | N/A (separate CRD) |\n| Experimental `sessionPersistence` (Option 2) | Yes | No (experimental) |\n\n---\n\n## Implementation-specific policies (recommended)\n\nEach Gateway API implementation provides its own policy resource for session affinity. Create the appropriate resource in the **same namespace** as your Helm release.\n\n### Envoy Gateway\n\n```yaml\napiVersion: gateway.envoyproxy.io/v1alpha1\nkind: BackendTrafficPolicy\nmetadata:\n name: -session-affinity\n namespace: \nspec:\n targetRefs:\n - group: gateway.networking.k8s.io\n kind: HTTPRoute\n name: -\n loadBalancer:\n type: ConsistentHash\n consistentHash:\n type: Cookie\n cookie:\n name: ATLROUTE_\n ttl: 10h\n```\n\n**Explore further:**\n\n- Envoy Gateway load balancing & session persistence: \n- Envoy Gateway `BackendTrafficPolicy` API: \n- Istio consistent-hash via `DestinationRule`: \n\n---\n\n## Experimental `sessionPersistence` on HTTPRoute\n\nThe Gateway API project has an **experimental** `sessionPersistence` field on HTTPRoute rules, tracked in **GEP-1619**. This field is **not** included in the standard-channel CRDs and will cause validation errors if those are installed.\n\n**Explore further:**\n\n- GEP-1619: \n- `SessionPersistence` field reference: \n- Experimental CRDs install (pick a release): \n\n!!!warning \"Implementation support varies\"\n Even with experimental CRDs installed, not all Gateway implementations support `sessionPersistence`. Check your implementation's conformance/support documentation.\n" }, { "path": "docs/docs/examples/ingress/INGRESS_NGINX.md", "content": "# NGINX Ingress Controller - with TLS termination\n[NGINX ingress controller](https://kubernetes.github.io/ingress-nginx/){.external} with automatic TLS certificate management using [cert-manager](https://cert-manager.io/docs/){.external} and certificates from [Let's Encrypt](https://letsencrypt.org/){.external}.\n\n!!!warning \"Using these instructions\" \n\n These instructions are for reference purposes, as such they should be used for development and testing purposes only! See the official instructions for [Deploying and configuring the controller](https://kubernetes.github.io/ingress-nginx/deploy/){.external}.\n\nThese instructions are composed of 3 high-level parts:\n\n1. Controller installation and configuration\n2. Certificate manager installation and configuration\n3. Ingress resource configuration\n\n## Controller installation and configuration\nWe recommend installing the controller using its official [Helm Charts](https://github.com/kubernetes/ingress-nginx/tree/master/charts/ingress-nginx){.external}. You can also use the instructions below.\n\n### 1. Add controller repository\nAdd the `ingress-nginx` Helm repository:\n```shell\nhelm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx\n```\nUpdate the repository:\n```shell\nhelm repo update\n```\n\n### 2. Install controller\nCreate a new namespace for the Ingress controller:\n```shell\nkubectl create namespace ingress\n```\nInstall the controller using Helm:\n```shell\nhelm install ingress-nginx ingress-nginx/ingress-nginx --namespace ingress\n```\n\n!!!info \"\"\n This will take couple of minutes.\n\nConfirm your ingress controller is installed:\n\n```\nkubectl get pods --namespace ingress\n```\n\n### 3. DNS setup\nManually provision a new DNS record via your cloud provider, [for instance AWS and Route53](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-to-elb-load-balancer.html){.external}, or dynamically using [external-dns](https://github.com/kubernetes-sigs/external-dns){.external}. There are also instructions on [how this can be done using the AWS CLI](DNS.md).\n\nOnce created, associate the DNS record with the auto provisioned load balancer that was created in [Step 2. above](#2-install-controller). To do this first identify the name of the auto provisioned LB, this can be done by examining the deployed ingress services i.e.:\n```shell\nkubectl get service -n ingress | grep ingress-nginx\n```\nthe output of this command should look something like...\n```shell\ningress-nginx-controller LoadBalancer 10.100.22.16 b834z142d8118406795a34df35e10b17-38927090.eu-west-1.elb.amazonaws.com 80:32615/TCP,443:31787/TCP 76m\ningress-nginx-controller-admission ClusterIP 10.100.5.36 443/TCP 76m\n```\nTake note of the `LoadBalancer` and using it as a value update the DNS record so that traffic is routed to it.\n\n!!!info \"\"\n It can take a few minutes for the DNS to resolve these changes.\n\n## Certificate manager installation and configuration\nKubernetes certificate management is handled using [cert-manager](https://cert-manager.io/){.external}.\n\n### 1. Install cert-manager\nAdd the cert-manager repository\n```shell\nhelm repo add jetstack https://charts.jetstack.io\n```\n\nUpdate repositories\n```shell\nhelm repo update\n```\n\nInstall the cert-manager using Helm\n```shell\nhelm install \\\n cert-manager jetstack/cert-manager \\\n --namespace cert-manager \\\n --create-namespace \\\n --version v1.3.1 \\\n --set installCRDs=true\n```\n\nConfirm the cert-manager is appropriately installed:\n```shell\nkubectl get pods --namespace cert-manager\n```\n\n### 2. Create certificate issuer\nUsing the `yaml` specification below create and apply the certificate `Issuer` resource:\n\n!!!info \"Namespace co-location\"\n Ensure that the certificate issuer is installed in the same namespace that the Atlassian product will be deployed to.\n\n```yaml\napiVersion: cert-manager.io/v1\nkind: Issuer\nmetadata:\n name: letsencrypt-prod\n namespace: \nspec:\n acme:\n # The ACME server URL\n server: https://acme-v02.api.letsencrypt.org/directory\n # Email address used for ACME registration\n email: \n # Name of a secret used to store the ACME account private key\n privateKeySecretRef:\n name: letsencrypt-prod\n # Enable the HTTP-01 challenge provider\n solvers:\n - http01:\n ingress:\n class: nginx\n```\nInstall the `Issuer` resource:\n```shell\nkubectl apply -f issuer.yaml\n```\n\n## Ingress resource configuration\nNow that the Ingress controller and certificate manager are setup the Ingress resource can be configured accordingly by updating the `values.yaml`.\n\n### 1. Ingress resource config\nFor TLS cert auto-provisioning and TLS termination update the `ingress` stanza within the products `values.yaml`:\n```yaml\ningress:\n create: true\n nginx: true\n maxBodySize: 250m\n host: \n path: \"/\"\n annotations:\n cert-manager.io/issuer: \"letsencrypt-prod\" # Using https://letsencrypt.org/\n https: true\n tlsSecretName: tls-certificate\n```\n\n!!!info \"Configuring the `host` value\"\n\n In this case the `` would correspond to the record name that was created in [3. DNS setup](#3-dns-setup) above\n\n## Bitbucket SSH configuration\n\n!!!warning \"Additional configuration\"\n Bitbucket requires additional Ingress config to allow for `SSH` access. See [NGINX Ingress controller config for SSH connections](../bitbucket/BITBUCKET_SSH.md) for details.\n\n---\n!!!tip \"Next step - Database\"\n\n Having created the Ingress controller continue with provisioning the next piece of prerequisite infrastructure, the [database](../../userguide/PREREQUISITES.md#provision-a-database)." }, { "path": "docs/docs/examples/jira/.pages", "content": "collapse_single_pages: false\nnav:\n - JIRA_OPENSEARCH.md\n - ...\n" }, { "path": "docs/docs/examples/jira/JIRA_OPENSEARCH.md", "content": "# Configuring OpenSearch for Jira\n\n!!!info \"Jira and Helm chart version\"\n OpenSearch is supported in Jira 11.2 and Helm chart 2.0.10 onwards.\n\nAs Jira instances grow in size and scale, the default search engine, Lucene, may be slower to index and return search results. To address this, Jira Data Center offers an alternative search engine as an opt-in feature — OpenSearch.\n\n## Deploy OpenSearch Helm Chart with Jira\n\n!!!warning \"Support disclaimer\"\n Atlassian does not officially support OpenSearch Helm chart that can be installed with the Jira Helm release. Should you encounter any issues with the deployment, maintenance and upgrades, reach out to the [vendor](https://github.com/opensearch-project/helm-charts/tree/main/charts/opensearch){.external}.\n Moreover, if you intend to deploy OpenSearch to a critical Kubernetes environment, make sure you follow all the best practices, i.e. deploy a multi node cluster, use taints and tolerations, affinity rules, sufficient resources requests, have DR and backup strategies etc.\n\n## Deploy with the default settings\n\nTo deploy OpenSearch Helm chart and automatically configure Jira to use it as a search platform, set the following in your Helm values file:\n\n```yaml\nopensearch:\n enabled: true\n```\nThis will:\n\n* auto-generate the initial OpenSearch admin password and create a Kubernetes secret with `OPENSEARCH_INITIAL_ADMIN_PASSWORD` key\n* deploy [OpenSearch Helm chart](https://github.com/opensearch-project/helm-charts/tree/main/charts/opensearch){.external} to the target namespace with the default settings: single node, 1Gi memory/1 vCPU resources requests, 10Gi storage request\n* configure Jira to use the deployed OpenSearch cluster by setting opensearch properties, which are written to `jira-config.properties` at startup. The following properties are configured: `search.platform=opensearch`, `opensearch.http.url=http://opensearch-cluster-master:9200`, `opensearch.username=admin`, and `opensearch.password`.\n\n## Override OpenSearch Helm chart values\n\nYou can configure your OpenSearch cluster and the deployment options by overriding any values that the [Helm chart](https://github.com/opensearch-project/helm-charts/blob/main/charts/opensearch/values.yaml){.external} exposes. OpenSearch values must be nested under `opensearch` stanza in your Helm values file, for example:\n\n```yaml\nopensearch:\n singleNode: false\n replicas: 5\n config:\n opensearch.yml: |\n cluster.name: opensearch-cluster\n```\n\n## Use an existing OpenSearch secret\n\nIf you have a pre-created Kubernetes secret with the OpenSearch admin password, you can reference it instead of having the chart auto-generate one:\n\n```yaml\nopensearch:\n enabled: true\n credentials:\n createSecret: false\n existingSecretRef:\n name: my-opensearch-secret\n```\n\nThe secret must contain a key named `OPENSEARCH_INITIAL_ADMIN_PASSWORD`.\n\n## Connect to an external OpenSearch instance\n\nIf you already have an OpenSearch cluster running outside of Kubernetes (or\nmanaged separately), you can configure Jira to use it without deploying the\nbundled OpenSearch Helm chart. OpenSearch properties are written to\n`jira-config.properties` at container startup via the\n`additionalConfigProperties` mechanism (see\n[Additional config properties](../../userguide/CONFIGURATION.md#additional-config-properties)).\n\nFirst, create a Kubernetes Secret containing the OpenSearch password:\n\n```bash\nkubectl create secret generic opensearch-credentials \\\n --from-literal=password=''\n```\n\nThen reference it in your Helm values file. The `additionalEnvironmentVariables`\nentry injects the secret as an environment variable, and\n`additionalConfigPropertiesExpandEnv` expands it into the property value at\nstartup:\n\n```yaml\njira:\n additionalEnvironmentVariables:\n - name: MY_OPENSEARCH_PASSWORD\n valueFrom:\n secretKeyRef:\n name: opensearch-credentials\n key: password\n\n additionalConfigProperties:\n - \"search.platform=opensearch\"\n - \"opensearch.http.url=http://opensearch-host:9200\"\n - \"opensearch.username=admin\"\n\n additionalConfigPropertiesExpandEnv:\n - \"opensearch.password={MY_OPENSEARCH_PASSWORD}\"\n```\n\nFor the full list of available OpenSearch properties, see\n[Configuring OpenSearch for Jira](https://confluence.atlassian.com/adminjiraserver/configuring-opensearch-for-jira-1620511851.html){.external}.\n" }, { "path": "docs/docs/examples/logging/efk/EFK.md", "content": "# Logging in a Kubernetes environment\n\n!!!warning Disclaimer\n **This functionality is not officially supported.** This document explains how to enable aggregated logging in your Kubernetes cluster. There are many ways to do this and this document showcases only a few of the options.\n\n## EFK stack\n\nA common Kubernetes logging pattern is the combination of `Elasticsearch`, `Fluentd`, and `Kibana`, known as *EFK Stack*. \n\n[Fluentd](https://www.fluentd.org/){.external} is an open-source and multi-platform log processor that collects data/logs from different sources, aggregates, and forwards them to multiple destinations. It is fully compatible with Docker and Kubernetes environments. \n\n[Elasticsearch](https://www.elastic.co/){.external} is a distributed open search and analytics engine for all types of data. \n\n[Kibana](https://www.elastic.co/kibana/){.external} is an open-source front-end application that sits on top of Elasticsearch, providing search and data visualization capabilities for data indexed in Elasticsearch.\n\nThere are different methods to deploy an EFK stack. We provide two deployment methods, the first is deploying EFK locally on Kubernetes, and the second is using a managed Elasticsearch instance outside the Kubernetes cluster. \n\n## Local EFK stack\n\nThis solution deploys the EFK stack inside the Kubernetes cluster. By setting `fluentd.enabled` value to `true`, Helm installs Fluentd on each of application pods. This means that after deployment all the product pods run Fluentd, which collects all the log files and sends them to the Fluentd aggregator container. \n\nTo complete the EFK stack you need to install an Elasticsearch cluster and Kibana, and successfully forward the aggregated datalog to Elasticsearch using Fluentd, which is already installed. \n\nFollow these steps to install Elasticsearch\n\n### 1. Install Elasticsearch\n\nInstall Elasticsearch using the instructions [documented here](../../bitbucket/BITBUCKET_ELASTICSEARCH.md). Once installed make sure Elasticsearch cluster is working as expected by first port forwarding the service\n\n```shell\nkubectl port-forward svc/elasticsearch-master 9200\n```\n\nyou can then `curl` the endpoint for the current state\n\n```shell\n$ curl localhost:9200\n{\n \"name\" : \"elasticsearch-master-0\",\n \"cluster_name\" : \"elasticsearch\",\n \"cluster_uuid\" : \"uNdYC-2nSdWVdzPCw9P7jQ\",\n \"version\" : {\n \"number\" : \"7.12.0\",\n \"build_flavor\" : \"default\",\n \"build_type\" : \"docker\",\n \"build_hash\" : \"78722783c38caa25a70982b5b042074cde5d3b3a\",\n \"build_date\" : \"2021-03-18T06:17:15.410153305Z\",\n \"build_snapshot\" : false,\n \"lucene_version\" : \"8.8.0\",\n \"minimum_wire_compatibility_version\" : \"6.8.0\",\n \"minimum_index_compatibility_version\" : \"6.0.0-beta1\"\n },\n \"tagline\" : \"You Know, for Search\"\n}\n```\n\n### 2. Enable Fluentd\n\nNow enable `Fluentd` and set the `hostname` for Elasticsearch in `values.yaml` as follows:\n\n```yaml\nfluentd:\n enabled: true\n elasticsearch:\n hostname: elasticsearch-master\n```\nFluentd tries to parse and send the data to Elasticsearch, but since it's not installed the data is lost. At this point you have logged data in the installed Elasticsearch, and you should install Kibana to complete the EFK stack deployment:\n\n### 3. Install Kibana\nWith the same version that was used for installing [Elasticsearch](../../bitbucket/BITBUCKET_ELASTICSEARCH.md), use the `imageTag` property to install Kibana:\n\n```shell\nhelm install kibana --namespace --set imageTag=\"7.9.3\" elastic/kibana\n```\n\nMake sure kibana is running by checking the deployment\n\n```shell\nkubectl get deployment\n```\nYou should see something like...\n```shell\nNAME READY UP-TO-DATE AVAILABLE AGE\nhelm-operator 1/1 1 1 23m\ningress-nginx-release-controller 1/1 1 1 22m\nkibana-kibana 1/1 1 1 25m\n```\nThrough port-forwarding you can access Kibana via `http://localhost:5601`\n```shell\nkubectl port-forward deployment/kibana-kibana 5601\n```\n To visualise the logs you need to create an index pattern and then look at the the data in the discovery part. To create the index pattern go to `Management` → `Stack Management` and then select `Kibana` → `Index Patterns`. \n\n## Managed EFK stack\n\nIn this solution [Elasticsearch is deployed as a managed AWS service](https://aws.amazon.com/elasticsearch-service/){.external} and lives outside of the Kubernetes cluster. This approach uses [Fluentbit](https://fluentbit.io/){.external} instead of `Fluentd` for log processing.\n\n???+ info \"Fluentbit\"\n\n `Fluentbit` is used to collect and aggregate log data inside the EKS cluster. It then sends this to an AWS Elasticsearch instance outside of the cluster.\n\n\nWhen a node inside an EKS cluster needs to call an AWS API, it needs to provide extended permissions. Amazon provides an image of `Fluentbit` that supports AWS service accounts,and using this you no longer need to follow the traditional way. All you need is to have an IAM role for the AWS service account on an EKS cluster. Using this service account, an AWS permission can be provided to the containers in any pod that use that service account. The result is that the pods on that node can call AWS APIs.\n\nYour first step is to configure IAM roles for Service Accounts (IRSA) for `Fluentbit`, to make sure you have an OIDC identity provider to use IAM roles for the service account in the cluster:\n\n```shell\neksctl utils associate-iam-oidc-provider \\\n --cluster \\\n --approve \n```\nThen create an IAM policy to limit the permissions to connect to the Elasticsearch cluster. Before this, you need to set the following environment variables: \n\n| Environment variable | Value | \n|-----------------------|------------------------------------------------------------------------------------|\n| KUBE_NAMESPACE | The namespace for kubernetes cluster |\n| ES_DOMAIN_NAME | Elasticsearch domain name | \n| ES_VERSION | Elasticsearch version |\n| ES_USER | Elasticsearch username | \n| ES_PASSWORD | Elasticsearch password (eg. `export ES_PASSWORD=\"$(openssl rand -base64 8)_Ek1$\"`) |\n| ACCOUNT_ID | AWS Account ID |\n| AWS_REGION | AWS region code |\n\nNow create the file `fluent-bit-policy.json` to define the policy itself:\n\n```shell\ncat < ~/environment/logging/fluent-bit-policy.json\n{\n \"Version\": \"2012-10-17\",\n \"Statement\": [\n {\n \"Action\": [\n \"es:ESHttp*\"\n ],\n \"Resource\": \"arn:aws:es:${AWS_REGION}:${ACCOUNT_ID}:domain/${ES_DOMAIN_NAME}\",\n \"Effect\": \"Allow\"\n }\n ]\n}\nEoF\n```\nNext initialize the policy:\n```shell\naws iam create-policy \\\n --policy-name fluent-bit-policy \\\n --policy-document file://~/environment/logging/fluent-bit-policy.json\n```\nCreate an IAM role for the service account:\n```shell\neksctl create iamserviceaccount \\\n --name fluent-bit \\\n --namespace dcd \\\n --cluster dcd-ap-southeast-2 \\\n --attach-policy-arn \"arn:aws:iam::${ACCOUNT_ID}:policy/fluent-bit-policy\" \\\n --approve \\\n --override-existing-serviceaccounts\n```\nConfirm that the service account with an Amazon Resource Name (ARN) of the IAM role is annotated:\n```shell\nkubectl describe serviceaccount fluent-bit\n```\nLook for output similar to:\n```yaml\nName: fluent-bit\nNamespace: elastic\nLabels: \nAnnotations: eks.amazonaws.com/role-arn: arn:aws:iam::000000000000:role/eksctl-your-cluster-name-addon-iamserviceac-Role1-0A0A0A0A0A0A0\nImage pull secrets: \nMountable secrets: fluent-bit-token-pgpss\nTokens: fluent-bit-token-pgpss\nEvents: \n```\nNow define the Elasticsearch domain\n\n!!!info \"\"\n\n This configuration will provision a public Elasticsearch cluster with Fine-Grained Access Control enabled and a built-in user database:\n\n```shell\ncat < ~/environment/logging/elasticsearch_domain.json\n{\n \"DomainName\": ${ES_DOMAIN_NAME},\n \"ElasticsearchVersion\": ${ES_VERSION},\n \"ElasticsearchClusterConfig\": {\n \"InstanceType\": \"r5.large.elasticsearch\",\n \"InstanceCount\": 1,\n \"DedicatedMasterEnabled\": false,\n \"ZoneAwarenessEnabled\": false,\n \"WarmEnabled\": false\n },\n \"EBSOptions\": {\n \"EBSEnabled\": true,\n \"VolumeType\": \"gp2\",\n \"VolumeSize\": 100\n },\n \"AccessPolicies\": \"{\\\"Version\\\":\\\"2012-10-17\\\",\\\"Statement\\\":[{\\\"Effect\\\":\\\"Allow\\\",\\\"Principal\\\":{\\\"AWS\\\":\\\"*\\\"},\\\"Action\\\":\\\"es:ESHttp*\\\",\\\"Resource\\\":\\\"arn:aws:es:${AWS_REGION}:${ACCOUNT_ID}:domain/${ES_DOMAIN_NAME}/*\\\"}]}\",\n \"SnapshotOptions\": {},\n \"CognitoOptions\": {\n \"Enabled\": false\n },\n \"EncryptionAtRestOptions\": {\n \"Enabled\": true\n },\n \"NodeToNodeEncryptionOptions\": {\n \"Enabled\": true\n },\n \"DomainEndpointOptions\": {\n \"EnforceHTTPS\": true,\n \"TLSSecurityPolicy\": \"Policy-Min-TLS-1-0-2019-07\"\n },\n \"AdvancedSecurityOptions\": {\n \"Enabled\": true,\n \"InternalUserDatabaseEnabled\": true,\n \"MasterUserOptions\": {\n \"MasterUserName\": ${ES_USER},\n \"MasterUserPassword\": ${ES_PASSWORD}\n }\n }\n}\nEOF\n```\nInitialize the Elasticsearch domain using the `elasticsearch_domain.json`\n\n```shell\naws es create-elasticsearch-domain \\\n --cli-input-json file://~/environment/logging/elasticsearch_domain.json\n```\n\n!!!info \"\"\n \n It takes a while for Elasticsearch clusters to change to an active state. Check the AWS Console to see the status of the cluster, and continue to the next step when the cluster is ready.\n\nAt this point you need to map roles to users in order to set fine-grained access control, because without this mapping all the requests to the cluster will result in permission errors. You should add the `Fluentbit` ARN as a backend role to the `all-access` role, which uses the Elasticsearch APIs. To find the `fluentbit` ARN run the following command and export the value of `ARN Role` into the `FLUENTBIT_ROLE` environment variable:\n```shell\neksctl get iamserviceaccount --cluster dcd-ap-southeast-2\n```\nThe output of this command should look similar to this:\n```shell\nNAMESPACE NAME ROLE ARN\nkube-system cluster-autoscaler arn:aws:iam::887464544476:role/eksctl-dcd-ap-southeast-2-addon-iamserviceac-Role1-1RSRFV0BQVE3E\n```\nTake note of the `ROLE ARN` and export it as the environment variable `FLUENTBIT_ROLE`\n```shell\nexport FLUENTBIT_ROLE=arn:aws:iam::887464544476:role/eksctl-dcd-ap-southeast-2-addon-iamserviceac-Role1-1RSRFV0BQVE3E\n```\nRetrieve the Elasticsearch endpoint and update the internal database:\n```shell\nexport ES_ENDPOINT=$(aws es describe-elasticsearch-domain --domain-name ngh-search-domain --output text --query \"DomainStatus.Endpoint\")\n```\n\n```shell\ncurl -sS -u \"${ES_DOMAIN_USER}:${ES_DOMAIN_PASSWORD}\" \\\n -X PATCH \\\n https://${ES_ENDPOINT}/_opendistro/_security/api/rolesmapping/all_access?pretty \\\n -H 'Content-Type: application/json' \\\n -d'\n[\n {\n \"op\": \"add\", \"path\": \"/backend_roles\", \"value\": [\"'${FLUENTBIT_ROLE}'\"]\n }\n]\n'\n```\nFinally, it is time to deploy the `Fluentbit` DaemonSet:\n```shell\nkubectl apply -f docs/docs/examples/logging/efk/managed_es/fluentbit.yaml\n```\nAfter a few minutes all pods should be up and in running status. you can open Kibana to visualise the logs. The endpoint for Kibana can be found in the Elasticsearch output tab in the AWS console, or you can run the following command:\n```shell\necho \"Kibana URL: https://${ES_ENDPOINT}/_plugin/kibana/\" \nKibana URL: https://search-domain-uehlb3kxledxykchwexee.ap-southeast-2.es.amazonaws.com/_plugin/kibana/\n```\n\nThe user and password for Kibana are the same as the master user credential that is set in Elasticsearch in the provisioning stage. Open Kibana in a browser and after login, create an index pattern and see the report in the `Discover` page. \n" }, { "path": "docs/docs/examples/logging/efk/local_es/elasticsearch.yaml", "content": "---\nclusterName: \"elasticsearch\"\nnodeGroup: \"master\"\n\n# The service that non master groups will try to connect to when joining the cluster\n# This should be set to clusterName + \"-\" + nodeGroup for your master group\nmasterService: \"\"\n\n# Elasticsearch roles that will be applied to this nodeGroup\n# These will be set as environment variables. E.g. node.master=true\nroles:\n master: \"true\"\n ingest: \"true\"\n data: \"true\"\n\nreplicas: 3\nminimumMasterNodes: 2\n\nesMajorVersion: \"\"\n\n# Allows you to add any config files in /usr/share/elasticsearch/config/\n# such as elasticsearch.yml and log4j2.properties\nesConfig: {}\n# elasticsearch.yml: |\n# key:\n# nestedkey: value\n# log4j2.properties: |\n# key = value\n\n# Extra environment variables to append to this nodeGroup\n# This will be appended to the current 'env:' key. You can use any of the kubernetes env\n# syntax here\nextraEnvs: []\n# - name: MY_ENVIRONMENT_VAR\n# value: the_value_goes_here\n\n# A list of secrets and their paths to mount inside the pod\n# This is useful for mounting certificates for security and for mounting\n# the X-Pack license\nsecretMounts: []\n# - name: elastic-certificates\n# secretName: elastic-certificates\n# path: /usr/share/elasticsearch/config/certs\n\nimage: \"docker.elastic.co/elasticsearch/elasticsearch\"\nimageTag: \"7.1.2\"\nimagePullPolicy: \"IfNotPresent\"\n\npodAnnotations: {}\n# iam.amazonaws.com/role: es-cluster\n\n# additionals labels\nlabels: {}\n\nesJavaOpts: \"-Xmx1g -Xms1g\"\n\nresources:\n requests:\n cpu: \"100m\"\n memory: \"1000Mi\"\n limits:\n cpu: \"100m\"\n memory: \"1000Mi\"\n\ninitResources: {}\n # limits:\n # cpu: \"25m\"\n # # memory: \"128Mi\"\n # requests:\n # cpu: \"25m\"\n# memory: \"128Mi\"\n\nsidecarResources: {}\n # limits:\n # cpu: \"25m\"\n # # memory: \"128Mi\"\n # requests:\n # cpu: \"25m\"\n# memory: \"128Mi\"\n\nnetworkHost: \"0.0.0.0\"\n\nvolumeClaimTemplate:\n accessModes: [ \"ReadWriteOnce\" ]\n resources:\n requests:\n storage: 10Gi\n\nrbac:\n create: false\n serviceAccountName: \"\"\n\npodSecurityPolicy:\n create: false\n name: \"\"\n spec:\n privileged: true\n fsGroup:\n rule: RunAsAny\n runAsUser:\n rule: RunAsAny\n seLinux:\n rule: RunAsAny\n supplementalGroups:\n rule: RunAsAny\n volumes:\n - secret\n - configMap\n - persistentVolumeClaim\n\npersistence:\n enabled: true\n annotations: {}\n\nextraVolumes: \"\"\n # - name: extras\n# emptyDir: {}\n\nextraVolumeMounts: \"\"\n # - name: extras\n # mountPath: /usr/share/extras\n# readOnly: true\n\nextraContainers: \"\"\n # - name: do-something\n # image: busybox\n# command: ['do', 'something']\n\nextraInitContainers: \"\"\n # - name: do-something\n # image: busybox\n# command: ['do', 'something']\n\n# This is the PriorityClass settings as defined in\n# https://kubernetes.io/docs/concepts/configuration/pod-priority-preemption/#priorityclass\npriorityClassName: \"\"\n\n# By default this will make sure two pods don't end up on the same node\n# Changing this to a region would allow you to spread pods across regions\nantiAffinityTopologyKey: \"kubernetes.io/hostname\"\n\n# Hard means that by default pods will only be scheduled if there are enough nodes for them\n# and that they will never end up on the same node. Setting this to soft will do this \"best effort\"\n#antiAffinity: \"hard\"\nantiAffinity: \"soft\"\n\n\n# This is the node affinity settings as defined in\n# https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#node-affinity-beta-feature\nnodeAffinity: {}\n\n# The default is to deploy all pods serially. By setting this to parallel all pods are started at\n# the same time when bootstrapping the cluster\npodManagementPolicy: \"Parallel\"\n\nprotocol: http\nhttpPort: 9200\ntransportPort: 9300\n\nservice:\n labels: {}\n labelsHeadless: {}\n type: ClusterIP\n nodePort: \"\"\n annotations: {}\n httpPortName: http\n transportPortName: transport\n loadBalancerSourceRanges: []\n\nupdateStrategy: RollingUpdate\n\n# This is the max unavailable setting for the pod disruption budget\n# The default value of 1 will make sure that kubernetes won't allow more than 1\n# of your pods to be unavailable during maintenance\nmaxUnavailable: 1\n\npodSecurityContext:\n fsGroup: 1000\n runAsUser: 1000\n\n# The following value is deprecated,\n# please use the above podSecurityContext.fsGroup instead\nfsGroup: \"\"\n\nsecurityContext:\n capabilities:\n drop:\n - ALL\n # readOnlyRootFilesystem: true\n runAsNonRoot: true\n runAsUser: 1000\n\n# How long to wait for elasticsearch to stop gracefully\nterminationGracePeriod: 120\n\nsysctlVmMaxMapCount: 262144\n\nreadinessProbe:\n failureThreshold: 3\n initialDelaySeconds: 60\n periodSeconds: 30\n successThreshold: 3\n timeoutSeconds: 15\n\n# https://www.elastic.co/guide/en/elasticsearch/reference/current/cluster-health.html#request-params wait_for_status\nclusterHealthCheckParams: \"wait_for_status=green&timeout=1s\"\n\n## Use an alternate scheduler.\n## ref: https://kubernetes.io/docs/tasks/administer-cluster/configure-multiple-schedulers/\n##\nschedulerName: \"\"\n\nimagePullSecrets: []\nnodeSelector: {}\ntolerations: []\n\n# Enabling this will publically expose your Elasticsearch instance.\n# Only enable this if you have security enabled on your cluster\ningress:\n enabled: false\n annotations: {}\n # kubernetes.io/ingress.class: nginx\n # kubernetes.io/tls-acme: \"true\"\n path: /\n hosts:\n - chart-example.local\n tls: []\n # - secretName: chart-example-tls\n # hosts:\n # - chart-example.local\n\nnameOverride: \"\"\nfullnameOverride: \"\"\n\n# https://github.com/elastic/helm-charts/issues/63\nmasterTerminationFix: false\n\nlifecycle: {}\n # preStop:\n # exec:\n # command: [\"/bin/sh\", \"-c\", \"echo Hello from the postStart handler > /usr/share/message\"]\n # postStart:\n # exec:\n # command:\n # - bash\n # - -c\n # - |\n # #!/bin/bash\n # # Add a template to adjust number of shards/replicas\n # TEMPLATE_NAME=my_template\n # INDEX_PATTERN=\"logstash-*\"\n # SHARD_COUNT=8\n # REPLICA_COUNT=1\n # ES_URL=http://localhost:9200\n # while [[ \"$(curl -s -o /dev/null -w '%{http_code}\\n' $ES_URL)\" != \"200\" ]]; do sleep 1; done\n# curl -XPUT \"$ES_URL/_template/$TEMPLATE_NAME\" -H 'Content-Type: application/json' -d'{\"index_patterns\":['\\\"\"$INDEX_PATTERN\"\\\"'],\"settings\":{\"number_of_shards\":'$SHARD_COUNT',\"number_of_replicas\":'$REPLICA_COUNT'}}'\n\nsysctlInitContainer:\n enabled: true\n\nkeystore: []\n" }, { "path": "docs/docs/examples/logging/efk/managed_es/fluentbit.yaml", "content": "---\napiVersion: rbac.authorization.k8s.io/v1\nkind: ClusterRole\nmetadata:\n name: fluent-bit-read\nrules:\n- apiGroups: [\"\"]\n resources:\n - namespaces\n - pods\n verbs: [\"get\", \"list\", \"watch\"]\n---\napiVersion: rbac.authorization.k8s.io/v1\nkind: ClusterRoleBinding\nmetadata:\n name: fluent-bit-read\nroleRef:\n apiGroup: rbac.authorization.k8s.io\n kind: ClusterRole\n name: fluent-bit-read\nsubjects:\n- kind: ServiceAccount\n name: fluent-bit\n namespace: ${KUBE_NAMESPACE}\n---\napiVersion: v1\nkind: ConfigMap\nmetadata:\n name: fluent-bit-config\n namespace: ${KUBE_NAMESPACE}\n labels:\n k8s-app: fluent-bit\ndata:\n # Configuration files: server, input, filters and output\n # ======================================================\n fluent-bit.conf: |\n [SERVICE]\n Flush 1\n Log_Level info\n Daemon off\n Parsers_File parsers.conf\n HTTP_Server On\n HTTP_Listen 0.0.0.0\n HTTP_Port 2020\n\n @INCLUDE input-kubernetes.conf\n @INCLUDE filter-kubernetes.conf\n @INCLUDE output-elasticsearch.conf\n\n input-kubernetes.conf: |\n [INPUT]\n Name tail\n Tag kube.*\n Path /var/log/containers/*.log\n Parser docker\n DB /var/log/flb_kube.db\n Mem_Buf_Limit 50MB\n Skip_Long_Lines On\n Refresh_Interval 10\n\n filter-kubernetes.conf: |\n [FILTER]\n Name kubernetes\n Match kube.*\n Kube_URL https://kubernetes.default.svc:443\n Kube_CA_File /var/run/secrets/kubernetes.io/serviceaccount/ca.crt\n Kube_Token_File /var/run/secrets/kubernetes.io/serviceaccount/token\n Kube_Tag_Prefix kube.var.log.containers.\n Merge_Log On\n Merge_Log_Key log_processed\n K8S-Logging.Parser On\n K8S-Logging.Exclude Off\n\n output-elasticsearch.conf: |\n [OUTPUT]\n Name es\n Match *\n Host ${ES_HOST}\n Port ${ES_PORT}\n TLS On\n AWS_Auth On\n AWS_Region ${AW_REGION}\n Retry_Limit 6\n\n parsers.conf: |\n [PARSER]\n Name bitbucket_log\n Format regex\n Regex ^(?