Repository: atlassian/data-center-helm-charts Branch: main Commit: 4e419503d489 Files: 516 Total size: 4.0 MB Directory structure: gitextract_ddpb32d0/ ├── .atlassian/ │ └── OWNER ├── .github/ │ ├── CODEOWNERS │ ├── ISSUE_TEMPLATE/ │ │ ├── FEATURE.yml │ │ └── config.yml │ ├── pull_request_template.md │ └── workflows/ │ ├── crc.yaml │ ├── dc-tests.yml │ ├── documentation-build.yaml │ ├── documentation-deploy.yaml │ ├── e2e-tf-deployment.yaml │ ├── kind.yaml │ ├── maven.yml │ ├── openshift.yaml │ ├── prepare-release.yaml │ ├── process-dashboard-test.yaml │ ├── release-charts.yaml │ ├── release-unit-tests.yaml │ ├── sync-grafana-dashboards.yaml │ └── update-lts-tags.yaml ├── .gitignore ├── .java-version ├── .pre-commit-config.yaml ├── BREAKING_CHANGES.md ├── CODE_OF_CONDUCT.md ├── CONTRIBUTING.md ├── DEVELOPMENT.md ├── LICENSE ├── Makefile ├── README.md ├── cr.yaml ├── docs/ │ ├── build/ │ │ └── Dockerfile │ ├── docs/ │ │ ├── .pages │ │ ├── README.md │ │ ├── artifacthub-repo.yml │ │ ├── assets/ │ │ │ ├── images/ │ │ │ │ ├── KubernetesOverview.xml │ │ │ │ └── ingress.xml │ │ │ └── stylesheets/ │ │ │ └── extra.css │ │ ├── containers/ │ │ │ ├── .pages │ │ │ ├── BAMBOO-AGENT.md │ │ │ ├── BAMBOO.md │ │ │ ├── BITBUCKET-MESH.md │ │ │ ├── BITBUCKET.md │ │ │ ├── CONFLUENCE.md │ │ │ ├── CROWD.md │ │ │ └── JIRA.md │ │ ├── examples/ │ │ │ ├── .pages │ │ │ ├── EXAMPLES.md │ │ │ ├── bamboo/ │ │ │ │ ├── .pages │ │ │ │ ├── AGENT_CAPABILITIES.md │ │ │ │ └── REMOTE_AGENTS.md │ │ │ ├── bitbucket/ │ │ │ │ ├── .pages │ │ │ │ ├── BITBUCKET_AWS_OPENSEARCH.md │ │ │ │ ├── BITBUCKET_ELASTICSEARCH.md │ │ │ │ ├── BITBUCKET_MESH.md │ │ │ │ ├── BITBUCKET_MIRRORS.md │ │ │ │ ├── BITBUCKET_OPENSEARCH.md │ │ │ │ ├── BITBUCKET_SESSION_AFFINITY.md │ │ │ │ └── BITBUCKET_SSH.md │ │ │ ├── cluster/ │ │ │ │ ├── AKS_SETUP.md │ │ │ │ ├── CLOUD_PROVIDERS.md │ │ │ │ ├── EKS_SETUP.md │ │ │ │ └── GKE_SETUP.md │ │ │ ├── confluence/ │ │ │ │ ├── .pages │ │ │ │ └── CONFLUENCE_OPENSEARCH.md │ │ │ ├── database/ │ │ │ │ ├── AMAZON_RDS.md │ │ │ │ └── CLOUD_PROVIDERS.md │ │ │ ├── external_libraries/ │ │ │ │ └── EXTERNAL_LIBS.md │ │ │ ├── ingress/ │ │ │ │ ├── CONTROLLERS.md │ │ │ │ ├── DNS.md │ │ │ │ ├── GATEWAY_API.md │ │ │ │ ├── GATEWAY_API_SESSION_AFFINITY.md │ │ │ │ └── INGRESS_NGINX.md │ │ │ ├── jira/ │ │ │ │ ├── .pages │ │ │ │ └── JIRA_OPENSEARCH.md │ │ │ ├── logging/ │ │ │ │ └── efk/ │ │ │ │ ├── EFK.md │ │ │ │ ├── local_es/ │ │ │ │ │ └── elasticsearch.yaml │ │ │ │ └── managed_es/ │ │ │ │ └── fluentbit.yaml │ │ │ └── storage/ │ │ │ ├── .pages │ │ │ ├── STORAGE.md │ │ │ ├── additional storage/ │ │ │ │ └── ADDTIONAL_STORAGE.md │ │ │ ├── aws/ │ │ │ │ ├── LOCAL_STORAGE.md │ │ │ │ ├── SHARED_STORAGE.md │ │ │ │ └── s3/ │ │ │ │ ├── CONFLUENCE.md │ │ │ │ └── JIRA.md │ │ │ └── nfs/ │ │ │ ├── NFS.md │ │ │ ├── nfs-server-example/ │ │ │ │ ├── .helmignore │ │ │ │ ├── Chart.yaml │ │ │ │ ├── templates/ │ │ │ │ │ ├── NOTES.txt │ │ │ │ │ ├── _helpers.tpl │ │ │ │ │ ├── service.yaml │ │ │ │ │ ├── serviceaccount.yaml │ │ │ │ │ ├── statefulset.yaml │ │ │ │ │ ├── storageclass.yaml │ │ │ │ │ └── tests/ │ │ │ │ │ ├── test-locking.yaml │ │ │ │ │ ├── test-performance.yaml │ │ │ │ │ └── test-pv.yaml │ │ │ │ └── values.yaml │ │ │ └── nfs-server-example-0.1.0.tgz │ │ ├── index.yaml │ │ ├── platforms/ │ │ │ ├── .pages │ │ │ ├── PLATFORMS.md │ │ │ └── openshift/ │ │ │ ├── OPENSHIFT.md │ │ │ └── OPENSHIFT_FAQ.md │ │ ├── troubleshooting/ │ │ │ ├── .pages │ │ │ ├── LIMITATIONS.md │ │ │ ├── SUPPORT_BOUNDARIES.md │ │ │ └── TROUBLESHOOTING.md │ │ └── userguide/ │ │ ├── .pages │ │ ├── CONFIGURATION.md │ │ ├── INSTALLATION.md │ │ ├── MIGRATION.md │ │ ├── OPERATION.md │ │ ├── PREREQUISITES.md │ │ ├── VERIFICATION.md │ │ ├── monitoring/ │ │ │ ├── .pages │ │ │ ├── PRE_CANNED_CHARTS.md │ │ │ └── PROMETHEUS.md │ │ ├── resource_management/ │ │ │ ├── JIRA_INDEX_SNAPSHOT.md │ │ │ ├── REQUESTS_AND_LIMITS.md │ │ │ └── RESOURCE_SCALING.md │ │ └── upgrades/ │ │ ├── .pages │ │ ├── HELM_CHART_UPGRADE.md │ │ └── PRODUCTS_UPGRADE.md │ ├── mkdocs.yml │ ├── overrides/ │ │ └── main.html │ └── requirements.txt ├── docs_internal/ │ └── ROUTING.md ├── mvnvm.properties ├── pom.xml ├── scripts/ │ └── generate_k8s_support_bundle.sh └── src/ ├── main/ │ ├── charts/ │ │ ├── README.md.gotmpl │ │ ├── bamboo/ │ │ │ ├── .helmignore │ │ │ ├── Changelog.md │ │ │ ├── Chart.yaml │ │ │ ├── README.md │ │ │ ├── grafana-dashboards/ │ │ │ │ └── overview.json │ │ │ ├── templates/ │ │ │ │ ├── NOTES.txt │ │ │ │ ├── _fluentd_templates.tpl │ │ │ │ ├── _helpers.tpl │ │ │ │ ├── config-jvm.yaml │ │ │ │ ├── configmap-additional-config.yaml │ │ │ │ ├── configmap-fluentd.yaml │ │ │ │ ├── configmap-init-properties.yaml │ │ │ │ ├── configmap-jmx-config.yaml │ │ │ │ ├── configmap-server-config.yaml │ │ │ │ ├── configmap-values-analytics.yaml │ │ │ │ ├── configmaps-grafana-dashboards.yaml │ │ │ │ ├── httproute.yaml │ │ │ │ ├── ingress.yaml │ │ │ │ ├── pdb.yaml │ │ │ │ ├── route.yaml │ │ │ │ ├── service-jms.yaml │ │ │ │ ├── service-jmx.yaml │ │ │ │ ├── service-monitor.yaml │ │ │ │ ├── service.yaml │ │ │ │ ├── serviceaccount.yaml │ │ │ │ ├── shared-home-pvc.yaml │ │ │ │ ├── statefulset.yaml │ │ │ │ └── tests/ │ │ │ │ ├── test-application-status.yaml │ │ │ │ ├── test-database-connectivity.yaml │ │ │ │ └── test-shared-home-permissions.yaml │ │ │ └── values.yaml │ │ ├── bamboo-agent/ │ │ │ ├── .helmignore │ │ │ ├── Changelog.md │ │ │ ├── Chart.yaml │ │ │ ├── README.md │ │ │ ├── templates/ │ │ │ │ ├── NOTES.txt │ │ │ │ ├── _helpers.tpl │ │ │ │ ├── config-jvm.yaml │ │ │ │ ├── deployment-agent.yaml │ │ │ │ └── serviceaccount.yaml │ │ │ └── values.yaml │ │ ├── bitbucket/ │ │ │ ├── .helmignore │ │ │ ├── Changelog.md │ │ │ ├── Chart.yaml │ │ │ ├── README.md │ │ │ ├── grafana-dashboards/ │ │ │ │ ├── bitbucket-mesh/ │ │ │ │ │ ├── mesh-grpc.json │ │ │ │ │ ├── mesh-overview.json │ │ │ │ │ ├── mesh-repair.json │ │ │ │ │ └── mesh-tickets.json │ │ │ │ ├── build-actions-thread-pool-stats.json │ │ │ │ ├── db-ops.json │ │ │ │ ├── event-thread-pool-stats.json │ │ │ │ ├── git-ops.json │ │ │ │ ├── io-pump-thread-pool-stats.json │ │ │ │ ├── nio-pump-thread-pool-stats.json │ │ │ │ ├── overview.json │ │ │ │ ├── scheduled-thread-pool-stats.json │ │ │ │ ├── ssh-session-stats.json │ │ │ │ ├── ticket-status.json │ │ │ │ └── webhooks-stats.json │ │ │ ├── templates/ │ │ │ │ ├── NOTES.txt │ │ │ │ ├── _fluentd_templates.tpl │ │ │ │ ├── _helpers.tpl │ │ │ │ ├── config-jvm-mesh.yaml │ │ │ │ ├── config-jvm.yaml │ │ │ │ ├── configmap-additional-config.yaml │ │ │ │ ├── configmap-fluentd.yaml │ │ │ │ ├── configmap-jmx-config.yaml │ │ │ │ ├── configmap-mesh-grafana-dashboards.yaml │ │ │ │ ├── configmap-mesh-scripts.yaml │ │ │ │ ├── configmap-values-analytics.yaml │ │ │ │ ├── configmaps-grafana-dashboards.yaml │ │ │ │ ├── httproute.yaml │ │ │ │ ├── ingress.yaml │ │ │ │ ├── job-mesh-add-nodes.yaml │ │ │ │ ├── job-mesh-configure.yaml │ │ │ │ ├── pdb.yaml │ │ │ │ ├── rbac.yaml │ │ │ │ ├── route.yaml │ │ │ │ ├── secret-clustering.yaml │ │ │ │ ├── secret-opensearch.yaml │ │ │ │ ├── service-hazelcast.yaml │ │ │ │ ├── service-jmx.yaml │ │ │ │ ├── service-mesh.yaml │ │ │ │ ├── service-monitor-mesh.yaml │ │ │ │ ├── service-monitor.yaml │ │ │ │ ├── service-ssh.yaml │ │ │ │ ├── service.yaml │ │ │ │ ├── serviceaccount.yaml │ │ │ │ ├── shared-home-pv.yaml │ │ │ │ ├── shared-home-pvc.yaml │ │ │ │ ├── statefulset-mesh.yaml │ │ │ │ ├── statefulset.yaml │ │ │ │ └── tests/ │ │ │ │ ├── test-application-status.yaml │ │ │ │ ├── test-database-connectivity.yaml │ │ │ │ └── test-shared-home-permissions.yaml │ │ │ └── values.yaml │ │ ├── common/ │ │ │ ├── .helmignore │ │ │ ├── Changelog.md │ │ │ ├── Chart.yaml │ │ │ ├── README.md │ │ │ └── templates/ │ │ │ ├── _jmx.tpl │ │ │ ├── _labels.tpl │ │ │ └── _names.tpl │ │ ├── confluence/ │ │ │ ├── .helmignore │ │ │ ├── Changelog.md │ │ │ ├── Chart.yaml │ │ │ ├── README.md │ │ │ ├── grafana-dashboards/ │ │ │ │ ├── cache-clearing.json │ │ │ │ ├── cluster-locks.json │ │ │ │ ├── database-load.json │ │ │ │ ├── hikari.json │ │ │ │ ├── overview.json │ │ │ │ ├── plugin-monitoring.json │ │ │ │ └── response-times.json │ │ │ ├── templates/ │ │ │ │ ├── NOTES.txt │ │ │ │ ├── _fluentd_templates.tpl │ │ │ │ ├── _helpers.tpl │ │ │ │ ├── config-jvm.yaml │ │ │ │ ├── configmap-additional-config.yaml │ │ │ │ ├── configmap-fluentd.yaml │ │ │ │ ├── configmap-jmx-config.yaml │ │ │ │ ├── configmap-server-config.yaml │ │ │ │ ├── configmap-values-analytics.yaml │ │ │ │ ├── configmaps-grafana-dashboards.yaml │ │ │ │ ├── httproute.yaml │ │ │ │ ├── ingress-setup.yaml │ │ │ │ ├── ingress-synchrony.yaml │ │ │ │ ├── ingress.yaml │ │ │ │ ├── pdb.yaml │ │ │ │ ├── rbac.yaml │ │ │ │ ├── route.yaml │ │ │ │ ├── secret-opensearch.yaml │ │ │ │ ├── service-hazelcast.yaml │ │ │ │ ├── service-jmx.yaml │ │ │ │ ├── service-monitor.yaml │ │ │ │ ├── service-synchrony.yaml │ │ │ │ ├── service.yaml │ │ │ │ ├── serviceaccount.yaml │ │ │ │ ├── shared-home-pvc.yaml │ │ │ │ ├── statefulset-synchrony.yaml │ │ │ │ ├── statefulset.yaml │ │ │ │ ├── synchrony-start-script.yaml │ │ │ │ └── tests/ │ │ │ │ ├── test-application-status.yaml │ │ │ │ ├── test-database-connectivity.yaml │ │ │ │ └── test-shared-home-permissions.yaml │ │ │ └── values.yaml │ │ ├── crowd/ │ │ │ ├── .helmignore │ │ │ ├── Changelog.md │ │ │ ├── Chart.yaml │ │ │ ├── README.md │ │ │ ├── grafana-dashboards/ │ │ │ │ └── overview.json │ │ │ ├── templates/ │ │ │ │ ├── NOTES.txt │ │ │ │ ├── _fluentd_templates.tpl │ │ │ │ ├── _helpers.tpl │ │ │ │ ├── config-jvm.yaml │ │ │ │ ├── configmap-additional-config.yaml │ │ │ │ ├── configmap-fluentd.yaml │ │ │ │ ├── configmap-jmx-config.yaml │ │ │ │ ├── configmap-server-config.yaml │ │ │ │ ├── configmap-values-analytics.yaml │ │ │ │ ├── configmaps-grafana-dashboards.yaml │ │ │ │ ├── httproute.yaml │ │ │ │ ├── ingress.yaml │ │ │ │ ├── pdb.yaml │ │ │ │ ├── route.yaml │ │ │ │ ├── service-jmx.yaml │ │ │ │ ├── service-monitor.yaml │ │ │ │ ├── service.yaml │ │ │ │ ├── serviceaccount.yaml │ │ │ │ ├── shared-home-pvc.yaml │ │ │ │ ├── statefulset.yaml │ │ │ │ └── tests/ │ │ │ │ ├── test-application-status.yaml │ │ │ │ └── test-shared-home-permissions.yaml │ │ │ └── values.yaml │ │ └── jira/ │ │ ├── .helmignore │ │ ├── Changelog.md │ │ ├── Chart.yaml │ │ ├── README.md │ │ ├── grafana-dashboards/ │ │ │ ├── cache-clearing.json │ │ │ ├── cluster-locks.json │ │ │ ├── database-load.json │ │ │ ├── general.json │ │ │ ├── indexing.json │ │ │ ├── response-times.json │ │ │ └── tasks.json │ │ ├── templates/ │ │ │ ├── NOTES.txt │ │ │ ├── _fluentd_templates.tpl │ │ │ ├── _helpers.tpl │ │ │ ├── config-jvm.yaml │ │ │ ├── configmap-additional-config.yaml │ │ │ ├── configmap-fluentd.yaml │ │ │ ├── configmap-jmx-config.yaml │ │ │ ├── configmap-server-config.yaml │ │ │ ├── configmap-values-analytics.yaml │ │ │ ├── configmaps-grafana-dashboards.yaml │ │ │ ├── httproute.yaml │ │ │ ├── ingress.yaml │ │ │ ├── pdb.yaml │ │ │ ├── route.yaml │ │ │ ├── secret-opensearch.yaml │ │ │ ├── service-jmx.yaml │ │ │ ├── service-monitor.yaml │ │ │ ├── service.yaml │ │ │ ├── serviceaccount.yaml │ │ │ ├── shared-home-pvc.yaml │ │ │ ├── statefulset.yaml │ │ │ └── tests/ │ │ │ ├── test-application-status.yaml │ │ │ ├── test-database-connectivity.yaml │ │ │ └── test-shared-home-permissions.yaml │ │ └── values.yaml │ ├── common_templates/ │ │ ├── README.md │ │ └── _gateway.tpl │ └── scripts/ │ ├── generate_chart_repo.sh │ ├── github_asset_uploader.sh │ ├── prepare_release.py │ ├── prepare_release_test.py │ ├── process_dashboard.py │ ├── process_dashboard_test.py │ └── update_grafana_dashboards.sh └── test/ ├── charts/ │ └── functest/ │ ├── .helmignore │ ├── Chart.yaml │ ├── README.md │ ├── templates/ │ │ ├── ingress-KITT.yaml │ │ ├── ingress-expose-node-EKS.yaml │ │ ├── ingress-expose-node-KITT.yaml │ │ └── service-expose-node.yaml │ └── values.yaml ├── config/ │ ├── bamboo/ │ │ ├── helm_parameters │ │ ├── values-AKS.yaml │ │ ├── values-EKS.yaml │ │ ├── values-GKE.yaml │ │ ├── values-KITT.yaml │ │ ├── values-agent.yaml │ │ └── values.yaml │ ├── bitbucket/ │ │ ├── helm_parameters │ │ ├── values-AKS.yaml │ │ ├── values-EKS.yaml │ │ ├── values-GKE.yaml │ │ ├── values-KITT.yaml │ │ └── values.yaml │ ├── confluence/ │ │ ├── helm_parameters │ │ ├── values-AKS.yaml │ │ ├── values-EKS.yaml │ │ ├── values-GKE.yaml │ │ ├── values-KITT.yaml │ │ └── values.yaml │ ├── crowd/ │ │ ├── helm_parameters │ │ ├── values-EKS.yaml │ │ └── values.yaml │ ├── jira/ │ │ ├── helm_parameters │ │ ├── values-AKS.yaml │ │ ├── values-EKS.yaml │ │ ├── values-GKE.yaml │ │ ├── values-KITT.yaml │ │ └── values.yaml │ ├── kind/ │ │ ├── backdoor-svc.yaml │ │ ├── common-values.yaml │ │ ├── envoy-proxy.yaml │ │ ├── gateway.yaml │ │ ├── hostpath-pv.yaml │ │ ├── kind-config.yml │ │ ├── nfs-values.yaml │ │ └── registry.yaml │ ├── logging/ │ │ ├── README.md │ │ ├── elasticsearch/ │ │ │ └── values-KITT.yaml │ │ └── kibana/ │ │ ├── ingress-kitt.yaml │ │ └── values-KITT.yaml │ ├── openshift/ │ │ ├── envoy-proxy.yaml │ │ ├── gateway.yaml │ │ ├── openshift.yaml │ │ └── shared-home-pvc.yaml │ └── shared-home/ │ └── shared-home-browser.yaml ├── infrastructure/ │ ├── cloudnativepg/ │ │ ├── README.md │ │ ├── cluster-template.yaml │ │ ├── init-scripts/ │ │ │ └── init-db.sql │ │ └── operator-values.yaml │ ├── elasticsearch/ │ │ └── elasticsearch-values.yaml │ ├── nfs-server/ │ │ ├── .helmignore │ │ ├── Chart.yaml │ │ ├── README.md │ │ ├── templates/ │ │ │ ├── NOTES.txt │ │ │ ├── _helpers.tpl │ │ │ ├── service.yaml │ │ │ ├── serviceaccount.yaml │ │ │ └── statefulset.yaml │ │ └── values.yaml │ └── postgres/ │ └── postgres-values.yaml ├── java/ │ └── test/ │ ├── AdditionalCertificatesTest.java │ ├── AdditionalConfigMapsTest.java │ ├── AdditionalConfigPropertiesTest.java │ ├── AdditionalFilesTest.java │ ├── AdditionalHostsTest.java │ ├── AdditionalLibrariesTest.java │ ├── BambooAgentTest.java │ ├── BitbucketMeshTest.java │ ├── BitbucketOpenSearchTest.java │ ├── BitbucketSshServiceTest.java │ ├── CloudNativePGTest.java │ ├── ClusteringTest.java │ ├── ConfluenceDebugFlagTest.java │ ├── ConfluenceOpenSearchTest.java │ ├── ConfluenceS3EnabledTest.java │ ├── ContainersTest.java │ ├── ContextPathTest.java │ ├── CustomPortTest.java │ ├── DatabaseTest.java │ ├── ElasticSearchTest.java │ ├── FluentdTest.java │ ├── ForcedConfigUpdateTest.java │ ├── GatewayTest.java │ ├── HelmLintTest.java │ ├── HelmOutputComparisonTest.java │ ├── HelmValuesAndAnalyticsTest.java │ ├── HostNamespacesTest.java │ ├── ImageTest.java │ ├── IngressTest.java │ ├── JiraOpenSearchTest.java │ ├── JiraS3EnabledTest.java │ ├── JmxMetricsTest.java │ ├── JvmResourcesTest.java │ ├── LicenseTest.java │ ├── LifecycleHooksTest.java │ ├── MirrorsTest.java │ ├── PodAnnotationsTest.java │ ├── PodDisruptionBudgetTest.java │ ├── PodTest.java │ ├── PriorityClassNameTest.java │ ├── ReadinessLivenessProbesTest.java │ ├── RequestsTest.java │ ├── SchedulerNameTest.java │ ├── SecurityContextTest.java │ ├── ServerConfigTest.java │ ├── ServiceAccountTest.java │ ├── ServiceTest.java │ ├── SetPermissionTest.java │ ├── StatefulSetUpdateTest.java │ ├── SynchronyTest.java │ ├── TestPodsTest.java │ ├── TopologySpreadConstraintsTest.java │ ├── TunnelTest.java │ ├── VolumesTest.java │ ├── helm/ │ │ └── Helm.java │ ├── jackson/ │ │ └── JsonNodeAssert.java │ ├── model/ │ │ ├── AnalyticsData.java │ │ ├── ClusterType.java │ │ ├── ConfigMap.java │ │ ├── Container.java │ │ ├── Deployment.java │ │ ├── Env.java │ │ ├── Kind.java │ │ ├── KubeResource.java │ │ ├── KubeResources.java │ │ ├── Pod.java │ │ ├── Product.java │ │ ├── Service.java │ │ ├── StatefulSet.java │ │ └── Synchrony.java │ └── postinstall/ │ ├── KubeClient.java │ ├── OpenSearchInstallTest.java │ ├── PostInstallStatusTest.java │ └── Utils.java ├── resources/ │ └── expected_helm_output/ │ ├── README.txt │ ├── bamboo/ │ │ ├── output.yaml │ │ └── values.yaml │ ├── bamboo-agent/ │ │ ├── output.yaml │ │ └── values.yaml │ ├── bitbucket/ │ │ ├── output.yaml │ │ └── values.yaml │ ├── confluence/ │ │ ├── output.yaml │ │ └── values.yaml │ ├── crowd/ │ │ ├── output.yaml │ │ └── values.yaml │ └── jira/ │ ├── output.yaml │ └── values.yaml └── scripts/ ├── download_logs.sh ├── helm_install.sh ├── helm_uninstall.sh ├── kind/ │ ├── configure_kind.sh │ ├── create_kind.sh │ └── deploy_app.sh ├── product_versions.py ├── shared_home_browser_install.sh ├── start_nfs_server.sh └── update_versions.py ================================================ FILE CONTENTS ================================================ ================================================ FILE: .atlassian/OWNER ================================================ abrokes ================================================ FILE: .github/CODEOWNERS ================================================ * @nanux @yzha645 @bianchi2 @kush982 @amierzwicki @pbhardwaj6 @jainanshul43 @jwitowski-atl ================================================ FILE: .github/ISSUE_TEMPLATE/FEATURE.yml ================================================ name: Feature request description: Do you have an idea or suggestion for a Helm charts improvement? title: "[Suggestion] - " labels: [suggestion, triage] body: - type: markdown attributes: value: | ## 💡 Feature requests only 💡 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/). - type: textarea id: suggestion-description attributes: label: Suggestion description: Describe your idea in detail, including the use case when it will be useful validations: required: true - type: dropdown id: version attributes: label: Product description: You can select multiple products options: - Jira - Confluence - Bitbucket - Other multiple: true validations: required: false - type: checkboxes id: terms attributes: label: Code of Conduct 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) options: - label: I agree to follow this project's Code of Conduct required: true ================================================ FILE: .github/ISSUE_TEMPLATE/config.yml ================================================ blank_issues_enabled: false contact_links: - name: ⚠️ Support boundaries ⚠️ url: https://atlassian.github.io/data-center-helm-charts/troubleshooting/SUPPORT_BOUNDARIES/ about: Please read the scope of support before raising an issue - name: Helm installation issues url: https://support.atlassian.com/contact/ about: Contact Atlassian Support with issues relating to Helm installation - name: Q & A Community forum url: https://community.atlassian.com/t5/Atlassian-Data-Center-on/gh-p/DC_Kubernetes about: For anyone who’s interested in learning more about K8s, and how they can deploy their Data Center products using the Helm Charts ================================================ FILE: .github/pull_request_template.md ================================================ ## Pull request description _Provide description for the PR_ ## Checklist - [ ] I have added unit tests - [ ] I have applied the change to all applicable products - [ ] The E2E test has passed (use `e2e` label) ================================================ FILE: .github/workflows/crc.yaml ================================================ # This workflow is for testing Helm charts in MicroShift name: DC Tests in MicroShift on: schedule: - cron: '0 3 */2 * *' # schedule the test to run every second day at 3:00am workflow_dispatch: push: branches: - main paths: - 'src/main/charts/bamboo/**' - 'src/main/charts/bamboo-agent/**' - 'src/main/charts/bitbucket/**' - 'src/main/charts/confluence/**' - 'src/main/charts/jira/**' - 'src/main/charts/crowd/**' pull_request_target: types: [ labeled ] jobs: jira: uses: ./.github/workflows/openshift.yaml with: dc_app: jira secrets: JIRA_LICENSE: "${{ secrets.JIRA_LICENSE }}" OPENSHIFT_PULL_SECRET: "${{ secrets.OPENSHIFT_PULL_SECRET }}" confluence: uses: ./.github/workflows/openshift.yaml with: dc_app: confluence secrets: CONFLUENCE_LICENSE: "${{ secrets.TF_VAR_CONFLUENCE_LICENSE }}" OPENSHIFT_PULL_SECRET: "${{ secrets.OPENSHIFT_PULL_SECRET }}" bitbucket: uses: ./.github/workflows/openshift.yaml with: dc_app: bitbucket secrets: BITBUCKET_LICENSE: "${{ secrets.TF_VAR_BITBUCKET_LICENSE }}" OPENSHIFT_PULL_SECRET: "${{ secrets.OPENSHIFT_PULL_SECRET }}" bamboo: uses: ./.github/workflows/openshift.yaml with: dc_app: bamboo secrets: BAMBOO_LICENSE: "${{ secrets.TF_VAR_BAMBOO_LICENSE }}" OPENSHIFT_PULL_SECRET: "${{ secrets.OPENSHIFT_PULL_SECRET }}" crowd: uses: ./.github/workflows/openshift.yaml with: dc_app: crowd secrets: OPENSHIFT_PULL_SECRET: "${{ secrets.OPENSHIFT_PULL_SECRET }}" ================================================ FILE: .github/workflows/dc-tests.yml ================================================ # This workflow is for testing Helm charts in KinD clusters name: DC apps tests in KinD on: schedule: - cron: '0 3 */2 * *' # schedule the test to run every second day at 3:00am push: branches: - main paths: - 'src/main/charts/bamboo/**' - 'src/main/charts/bamboo-agent/**' - 'src/main/charts/bitbucket/**' - 'src/main/charts/confluence/**' - 'src/main/charts/jira/**' - 'src/main/charts/crowd/**' workflow_dispatch: pull_request_target: types: [ labeled ] jobs: jira: uses: ./.github/workflows/kind.yaml with: dc_app: jira secrets: JIRA_LICENSE: "${{ secrets.JIRA_LICENSE }}" confluence: uses: ./.github/workflows/kind.yaml with: dc_app: confluence secrets: CONFLUENCE_LICENSE: "${{ secrets.TF_VAR_CONFLUENCE_LICENSE }}" bitbucket: uses: ./.github/workflows/kind.yaml with: dc_app: bitbucket secrets: BITBUCKET_LICENSE: "${{ secrets.TF_VAR_BITBUCKET_LICENSE }}" bamboo: uses: ./.github/workflows/kind.yaml with: dc_app: bamboo secrets: BAMBOO_LICENSE: "${{ secrets.TF_VAR_BAMBOO_LICENSE }}" crowd: uses: ./.github/workflows/kind.yaml with: dc_app: crowd ================================================ FILE: .github/workflows/documentation-build.yaml ================================================ name: Documentation - Build on: pull_request: jobs: deploy: runs-on: ubuntu-24.04 steps: - uses: actions/checkout@v4 - uses: actions/setup-python@v5 with: python-version: 3.x - name: Install mkdocs requirements run: pip install -r requirements.txt working-directory: docs - name: Publish documentation to gp-pages branch run: mkdocs build working-directory: docs ================================================ FILE: .github/workflows/documentation-deploy.yaml ================================================ name: Documentation - Deploy on: push: branches: - main jobs: deploy: runs-on: ubuntu-24.04 steps: - uses: actions/checkout@v4 - uses: actions/setup-python@v5 with: python-version: 3.x - name: Install mkdocs requirements run: pip install -r requirements.txt working-directory: docs - name: Publish documentation to gp-pages branch run: mkdocs gh-deploy --force working-directory: docs ================================================ FILE: .github/workflows/e2e-tf-deployment.yaml ================================================ name: Helm Charts E2E Testing on: schedule: - cron: '0 3 */2 * *' # schedule the test to run every second day at 3:00am push: branches: - main paths: - 'src/main/charts/bamboo/**' - 'src/main/charts/bamboo-agent/**' - 'src/main/charts/bitbucket/**' - 'src/main/charts/confluence/**' - 'src/main/charts/jira/**' - 'src/main/charts/crowd/**' pull_request_target: types: [ labeled ] workflow_dispatch: inputs: use_gateway_api: description: 'Use Gateway API (Envoy Gateway) instead of NGINX Ingress' required: false type: boolean default: false terraform_branch: description: 'Terraform repo branch to use (leave empty for latest LTS tag)' required: false type: string default: '' jobs: test: if: ${{ github.event.label.name == 'e2e' || github.event_name == 'push' || github.event_name == 'workflow_dispatch' || github.event_name == 'schedule' }} name: Deploy Infrastructure and Run E2E Tests runs-on: ubuntu-24.04 permissions: id-token: write contents: read env: AWS_DEFAULT_REGION: us-east-1 TF_VAR_bamboo_license: ${{ secrets.TF_VAR_BAMBOO_LICENSE }} TF_VAR_confluence_license: ${{ secrets.TF_VAR_CONFLUENCE_LICENSE }} TF_VAR_bitbucket_license: ${{ secrets.TF_VAR_BITBUCKET_LICENSE }} TF_VAR_crowd_license: ${{ secrets.TF_VAR_CROWD_LICENSE }} TF_VAR_bamboo_admin_password: ${{ secrets.TF_VAR_BAMBOO_ADMIN_PASSWORD }} TF_VAR_crowd_admin_password: ${{ secrets.TF_VAR_CROWD_ADMIN_PASSWORD }} TF_VAR_bitbucket_admin_password: ${{ secrets.TF_VAR_BITBUCKET_ADMIN_PASSWORD }} TF_VAR_kinesis_log_producers_role_arns: ${{ secrets.TF_VAR_KINESIS_LOG_PRODUCERS_ROLE_ARNS }} TF_VAR_osquery_fleet_enrollment_secret_name: ${{ secrets.TF_VAR_OSQUERY_FLEET_ENROLLMENT_SECRET_NAME }} TF_VAR_osquery_fleet_entrollment_host: ${{ secrets.TF_VAR_OSQUERY_FLEET_ENROLLMENT_HOST }} TF_VAR_crowdstrike_secret_name: ${{ secrets.TF_VAR_CROWDSTRIKE_SECRET_NAME }} TF_VAR_crowdstrike_kms_key_name: ${{ secrets.TF_VAR_CROWDSTRIKE_KMS_KEY_NAME }} TF_VAR_crowdstrike_aws_account_id: ${{ secrets.TF_VAR_CROWDSTRIKE_AWS_ACCOUNT_ID }} USE_DOMAIN: "true" USE_GATEWAY_API: ${{ github.event.inputs.use_gateway_api || 'false' }} steps: - name: Checkout Helm charts uses: actions/checkout@v4 with: fetch-depth: 0 ref: ${{ github.event.pull_request.head.sha }} - name: Install the latest Terraform run: | # check existing version terraform -version || true # download the latest URL=$(curl -fsSL https://api.releases.hashicorp.com/v1/releases/terraform/latest | jq -r '.builds[] | select((.arch=="amd64") and (.os=="linux")).url') curl -s -o /tmp/terraform.zip ${URL} echo A | unzip /tmp/terraform.zip -d /usr/local/bin/ rm /tmp/terraform.zip # check the latest version terraform -version - name: Pin Kubectl version uses: azure/setup-kubectl@v3.0 with: version: 'v1.30.0' - name: Install Helm uses: azure/setup-helm@v1 with: version: v3.15.3 - name: Execute helm dependency update for Helm charts run: | helm dependency update src/main/charts/bamboo helm dependency update src/main/charts/bamboo-agent helm dependency update src/main/charts/bitbucket helm dependency update src/main/charts/confluence helm dependency update src/main/charts/jira helm dependency update src/main/charts/crowd - name: Checkout Deployment Automation run: | DEPLOYMENT_REPO='https://github.com/atlassian-labs/data-center-terraform.git' CUSTOM_BRANCH="${{ github.event.inputs.terraform_branch }}" if [ -n "$CUSTOM_BRANCH" ]; then echo "Using custom branch '${CUSTOM_BRANCH}' of Deployment Automation." git clone -b $CUSTOM_BRANCH $DEPLOYMENT_REPO tf else LTS=$(git ls-remote --tags --exit-code --refs "$DEPLOYMENT_REPO" \ | sed -E 's/^[[:xdigit:]]+[[:space:]]+refs\/tags\/(.+)/\1/g' \ | grep '^[0-9]*.[0-9]*.[0-9]*$' | sort -V | tail -1) echo "Using LTS version('${LTS}') of Deployment Automation to provision the infrastructure for Atlassian DC Products." git clone -b $LTS $DEPLOYMENT_REPO tf fi - name: Setup test environment uses: actions/setup-go@v3 with: go-version: '1.18' - name: Setup Python environment uses: actions/setup-python@v5 with: python-version: '3.9.14' - run: | python -m pip install --upgrade pip pip install boto3 - name: Install test dependencies id: setup-dependencies working-directory: tf/test/ run: | go version go get -v -t -d ./... && go mod tidy echo ::set-output name=exit_code::$? - name: Add private SSH key for Bitbucket tests uses: shimataro/ssh-key-action@v2 with: key: ${{ secrets.BITBUCKET_E2E_TEST_PRIV_SSH_KEY }} name: bitbucket-e2e # optional known_hosts: dummy-entry if_key_exists: fail # replace / ignore / fail; optional (defaults to fail) - name: Add public SSH key for Bitbucket tests run: | echo ${{ secrets.BITBUCKET_E2E_TEST_PUB_SSH_KEY }} > /home/runner/.ssh/bitbucket-e2e.pub - name: Configure AWS Credentials uses: aws-actions/configure-aws-credentials@master with: aws-region: us-east-1 role-to-assume: ${{ secrets.AWS_IAM_ROLE }} role-session-name: DCTerraformHelmSession role-duration-seconds: 7200 - name: Deploy the infrastructure, install helm charts, run E2E tests, and cleanup id: e2e-test working-directory: tf/test/ run: | set -o pipefail # Create test output directory mkdir e2etest/artifacts # Add root of helm chart repo to the config template cat << EOF >> ./e2etest/test-config.tfvars.tmpl # install local helm charts local_helm_charts_path="$(dirname $(dirname $(pwd)))/src/main/charts" confluence_install_local_chart = true jira_install_local_chart = true bitbucket_install_local_chart = true bamboo_install_local_chart = true crowd_install_local_chart = true EOF # Append Gateway API toggle if enabled if [ "$USE_GATEWAY_API" = "true" ]; then echo 'use_gateway_api = true' >> ./e2etest/test-config.tfvars.tmpl echo "Gateway API mode enabled (Envoy Gateway will replace NGINX Ingress)" else echo "NGINX Ingress mode (default)" fi # Deploy infrastructure, install helm charts, run e2e tests, and cleanup all # boto3 ignores AWS creds env vars for some reason mkdir -p ~/.aws 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 go test ./e2etest -v -timeout 85m -run Installer | tee ./e2etest/artifacts/e2etest.log - name: Upload test log files if: always() uses: actions/upload-artifact@v4 with: name: e2e-test-artifacts path: tf/test/e2etest/artifacts/ ================================================ FILE: .github/workflows/kind.yaml ================================================ name: Test DC App in a KinD Cluster on: workflow_call: inputs: dc_app: required: true type: string secrets: BITBUCKET_LICENSE: description: 'Bitbucket license' CONFLUENCE_LICENSE: description: 'Confluence license' JIRA_LICENSE: description: 'Jira license' BAMBOO_LICENSE: description: 'Bamboo license' jobs: kind-testing: if: ${{ github.event.label.name == 'e2e' || github.event_name == 'push' || github.event_name == 'workflow_dispatch' || github.event_name == 'schedule' }} runs-on: ubuntu-24.04 env: # See: https://github.com/kubernetes-sigs/kind/tags KIND_VERSION: "v0.27.0" # See: https://hub.docker.com/r/kindest/node/tags K8S_VERSION: "v1.32.2" DC_APP: ${{inputs.dc_app}} LICENSE: ${{ secrets[format('{0}_LICENSE', inputs.dc_app)] }} steps: - name: Checkout code uses: actions/checkout@v4 with: fetch-depth: 0 ref: ${{ github.event.pull_request.head.sha }} - name: Pin Kubectl version uses: azure/setup-kubectl@v4 with: version: 'v1.32.2' - name: Pin Helm version uses: azure/setup-helm@v3 with: version: v3.17.2 - name: Create KinD cluster run: | src/test/scripts/kind/create_kind.sh - name: Install KinD tooling run: | src/test/scripts/kind/configure_kind.sh - name: Deploy postgres database run: | source src/test/scripts/kind/deploy_app.sh deploy_postgres - name: Create db, admin and license secrets run: | source src/test/scripts/kind/deploy_app.sh create_secrets - name: Deploy ${{inputs.dc_app}} run: | source src/test/scripts/kind/deploy_app.sh deploy_app - name: Verify ${{inputs.dc_app}} status run: | source src/test/scripts/kind/deploy_app.sh verify_gateway_ingress - name: Verify ${{inputs.dc_app}} grafana dashboards run: | source src/test/scripts/kind/deploy_app.sh verify_dashboards - name: Test scaling ${{inputs.dc_app}} run: | echo "[INFO]: Scaling ${DC_APP} to 2 replicas" kubectl scale sts/${DC_APP} --replicas=2 -n atlassian sleep 10 kubectl wait --for=condition=ready pod/${DC_APP}-1 -n atlassian --timeout=360s - name: Verify ${{inputs.dc_app}} OpenSearch integration run: | source src/test/scripts/kind/deploy_app.sh verify_opensearch - name: Verify ${{inputs.dc_app}} metrics availability run: | source src/test/scripts/kind/deploy_app.sh verify_metrics - name: Verify Gateway API integration run: | source src/test/scripts/kind/deploy_app.sh verify_gateway - name: Get debug info if: always() run: | 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}} - name: Upload test log files if: always() uses: actions/upload-artifact@v4 with: name: kind-artifacts-${{inputs.dc_app}} path: logs/ ================================================ FILE: .github/workflows/maven.yml ================================================ # This workflow will build a Java project with Maven # For more information see: https://help.github.com/actions/language-and-framework-guides/building-and-testing-java-with-maven name: Maven unit tests on: push: branches: - main - /.*-stable/ pull_request: jobs: build: runs-on: ubuntu-24.04 steps: - uses: actions/checkout@v4 - name: Set up JDK 11 uses: actions/setup-java@v1 with: java-version: 11 - name: Install Helm uses: azure/setup-helm@v3 with: version: v3.15.3 - name: Execute helm dependency update for bamboo chart run: helm dependency update src/main/charts/bamboo - name: Execute helm dependency update for bamboo-agent chart run: helm dependency update src/main/charts/bamboo-agent - name: Execute helm dependency update for bitbucket chart run: helm dependency update src/main/charts/bitbucket - name: Execute helm dependency update for confluence chart run: helm dependency update src/main/charts/confluence - name: Execute helm dependency update for crowd chart run: helm dependency update src/main/charts/crowd - name: Execute helm dependency update for jira chart run: helm dependency update src/main/charts/jira - name: Run tests with Maven run: mvn -B test ================================================ FILE: .github/workflows/openshift.yaml ================================================ name: MicroShift Tests on: workflow_call: inputs: dc_app: required: true type: string secrets: BITBUCKET_LICENSE: description: 'Bitbucket license' CONFLUENCE_LICENSE: description: 'Confluence license' JIRA_LICENSE: description: 'Jira license' BAMBOO_LICENSE: description: 'Bamboo license' OPENSHIFT_PULL_SECRET: description: 'OpenShift Pull Secret' jobs: microshift: if: ${{ github.event.label.name == 'e2e' || github.event_name == 'push' || github.event_name == 'workflow_dispatch' || github.event_name == 'schedule' }} runs-on: ubuntu-24.04 env: DC_APP: ${{inputs.dc_app}} LICENSE: ${{ secrets[format('{0}_LICENSE', inputs.dc_app)] }} OPENSHIFT_PULL_SECRET: ${{ secrets.OPENSHIFT_PULL_SECRET }} KUBECONFIG: /home/runner/.crc/machines/crc/kubeconfig steps: - name: Checkout uses: actions/checkout@v4 with: fetch-depth: 0 - name: Write pull secret file run: | echo "${OPENSHIFT_PULL_SECRET}" | base64 -d > pull-secret.txt - name: Fetch crc binary run: | CRC_VERSION="2.49.0" wget -q https://developers.redhat.com/content-gateway/file/pub/openshift-v4/clients/crc/${CRC_VERSION}/crc-linux-amd64.tar.xz tar -xvf crc-linux-amd64.tar.xz sudo cp crc-linux-${CRC_VERSION}-amd64/crc /usr/bin/crc sudo chmod a+x /usr/bin/crc - name: Fetch oc binary run: | wget -q https://mirror.openshift.com/pub/openshift-v4/clients/ocp/stable-4.18/openshift-client-linux.tar.gz tar -xvf openshift-client-linux.tar.gz sudo cp oc /usr/bin/oc sudo chmod a+x /usr/bin/oc - name: Install required virtualization software run: | sudo apt-get update sudo apt install qemu-kvm libvirt-daemon libvirt-daemon-system virtiofsd sudo usermod -a -G libvirt $USER - name: Free up disk run: | sudo rm -rf /usr/share/dotnet sudo rm -rf /usr/local/lib/android sudo rm -rf /opt/ghc sudo rm -rf "/usr/local/share/boost" sudo rm -rf /opt/hostedtoolcache/CodeQL sudo docker image prune --all --force sudo swapoff -a sudo rm -f /mnt/swapfile - name: Set crc config and microshift profile run: | crc config set consent-telemetry no crc config set network-mode user crc config set preset microshift - name: Setup the crc run: sudo -su $USER crc setup - name: Start MicroShift run: sudo -su $USER crc start -p pull-secret.txt --log-level debug - name: Create atlassian namespace run: | oc create namespace atlassian - name: Grant anyuid SCC for the default service account run: | SCC=("anyuid") for i in ${SCC[@]} ; do oc adm policy add-scc-to-user ${i} system:serviceaccount:atlassian:default done - name: Create shared home pvc run: | oc apply -f src/test/config/openshift/shared-home-pvc.yaml - name: Install Gateway API + Envoy Gateway run: | # Gateway API CRDs oc apply -f https://github.com/kubernetes-sigs/gateway-api/releases/download/v1.2.1/standard-install.yaml 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 oc wait --for condition=established --timeout=60s crd/gateways.gateway.networking.k8s.io oc wait --for condition=established --timeout=60s crd/httproutes.gateway.networking.k8s.io oc wait --for condition=established --timeout=60s crd/gatewayclasses.gateway.networking.k8s.io oc wait --for condition=established --timeout=60s crd/envoyproxies.gateway.envoyproxy.io # Envoy Gateway (installs into envoy-gateway-system) # OpenShift admission can reject fixed runAsUser/seccomp settings unless the # service accounts are allowed to use a more permissive SCC. oc create namespace envoy-gateway-system --dry-run=client -o yaml | oc apply -f - # Pre-grant SCCs to all service accounts in the namespace so Helm hooks can run # even before the chart-created ServiceAccounts exist. oc adm policy add-scc-to-group anyuid system:serviceaccounts:envoy-gateway-system || true oc adm policy add-scc-to-group privileged system:serviceaccounts:envoy-gateway-system || true helm install eg oci://docker.io/envoyproxy/gateway-helm \ --version v1.2.5 \ --namespace envoy-gateway-system \ --set deployment.envoyGateway.resources.requests.cpu=50m \ --set deployment.envoyGateway.resources.requests.memory=100Mi \ --skip-crds \ --timeout=600s \ --wait || { \ oc get all -n envoy-gateway-system || true; \ oc get events -n envoy-gateway-system --sort-by='.lastTimestamp' | tail -n 200 || true; \ exit 1; \ } oc wait --for=condition=available deployment/envoy-gateway \ --namespace envoy-gateway-system \ --timeout=300s # EnvoyProxy CR configures the proxy Service as ClusterIP (default for OpenShift; an OpenShift Route will handle external access). oc apply -f src/test/config/openshift/envoy-proxy.yaml # GatewayClass references the EnvoyProxy CR via parametersRef cat << EOF | oc apply -f - apiVersion: gateway.networking.k8s.io/v1 kind: GatewayClass metadata: name: eg spec: controllerName: gateway.envoyproxy.io/gatewayclass-controller parametersRef: group: gateway.envoyproxy.io kind: EnvoyProxy name: openshift-proxy-config namespace: envoy-gateway-system EOF 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; } # Create test Gateway oc apply -f src/test/config/openshift/gateway.yaml 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; } # Wait for data-plane oc wait --for=condition=Available deployment \ -n envoy-gateway-system \ -l gateway.envoyproxy.io/owning-gateway-name=atlassian-gateway \ --timeout=300s || { \ oc get deployments -n envoy-gateway-system -o wide; \ oc get pods -n envoy-gateway-system -o wide; \ oc describe deployment -n envoy-gateway-system -l gateway.envoyproxy.io/owning-gateway-name=atlassian-gateway || true; \ oc get events -n envoy-gateway-system --sort-by='.lastTimestamp' | tail -n 200 || true; \ exit 1; \ } # Create an OpenShift Route so atlassian.apps.crc.testing reaches the # Envoy proxy Service without port-forward or Host headers. ENVOY_SVC=$(oc get svc -n envoy-gateway-system \ -l gateway.envoyproxy.io/owning-gateway-name=atlassian-gateway \ -o jsonpath='{.items[0].metadata.name}' 2>/dev/null || true) if [ -z "${ENVOY_SVC}" ]; then echo "[ERROR]: Envoy Gateway proxy service not found" oc get svc -n envoy-gateway-system -o wide || true exit 1 fi oc -n envoy-gateway-system expose svc/${ENVOY_SVC} \ --name atlassian-gateway-proxy \ --hostname atlassian.apps.crc.testing || true # Log the Route and Endpoint details for debugging oc -n envoy-gateway-system get route atlassian-gateway-proxy -o yaml || true oc -n envoy-gateway-system get endpoints ${ENVOY_SVC} -o yaml || true - name: Deploy postgres database run: | source src/test/scripts/kind/deploy_app.sh deploy_postgres - name: Create db, admin and license secrets run: | source src/test/scripts/kind/deploy_app.sh create_secrets - name: Deploy ${{inputs.dc_app}} run: | 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" source src/test/scripts/kind/deploy_app.sh deploy_app - name: Verify ${{inputs.dc_app}} status run: | export OPENSHIFT_VALUES="1" source src/test/scripts/kind/deploy_app.sh verify_gateway_ingress - name: Verify ${{inputs.dc_app}} metrics availability run: | source src/test/scripts/kind/deploy_app.sh verify_metrics - name: Verify ${{inputs.dc_app}} analytics value run: | source src/test/scripts/kind/deploy_app.sh verify_openshift_analytics - name: Verify Gateway API integration run: | source src/test/scripts/kind/deploy_app.sh verify_gateway - name: Get debug info if: always() run: | 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}} - name: Upload test log files if: always() uses: actions/upload-artifact@v4 with: name: kind-artifacts-${{inputs.dc_app}} path: logs/ ================================================ FILE: .github/workflows/prepare-release.yaml ================================================ name: Prepare Release on: push: branches: - release/* jobs: prepare-release: env: GH_TOKEN: ${{ secrets.GITHUB_TOKEN }} runs-on: ubuntu-24.04 steps: - name: Checkout code uses: actions/checkout@v4 with: fetch-depth: 0 ref: refs/heads/main - name: Set up JDK 11 uses: actions/setup-java@v1 with: java-version: 11 - name: Install Helm uses: azure/setup-helm@v3 with: version: v3.15.3 - name: Setup Python environment uses: actions/setup-python@v5 with: python-version: '3.9.14' - name: Install Python dependencies run: | python -m pip install --upgrade pip gitpython ruamel_yaml - name: Install Helm Docs uses: envoy/install-helm-docs@v1.0.0 with: version: 1.12.0 - name: Generate changelog and Chart annotations run: | echo "[INFO]: Preparing release ${GITHUB_REF_NAME##*/}" python src/main/scripts/prepare_release.py ${GITHUB_REF_NAME##*/} - name: Update README files with helm-docs run: | cd src/main/charts helm-docs - name: Configure Git run: | git config --global user.name "$GITHUB_ACTOR" git config --global user.email "$GITHUB_ACTOR@users.noreply.github.com" - name: Lint yamls with ah cli run: | docker run --workdir="/charts" -u root -v ${GITHUB_WORKSPACE}/src/main/charts:/charts artifacthub/ah ah lint - name: Commit changes and raise a PR run: | git checkout ${GITHUB_REF_NAME} git add -A git commit -m "Prepare release ${GITHUB_REF_NAME##*/}" git push origin ${GITHUB_REF_NAME} gh pr create --title "Release/${GITHUB_REF_NAME##*/}" --body "Prepare to release ${GITHUB_REF_NAME##*/}" --base main --head ${GITHUB_REF_NAME} ================================================ FILE: .github/workflows/process-dashboard-test.yaml ================================================ name: Process Dashboard Script Testing on: push: paths: - 'src/main/scripts/process_dash*' workflow_dispatch: jobs: run-process-dashboard-tests: runs-on: ubuntu-24.04 steps: - name: Checkout code uses: actions/checkout@v4 with: fetch-depth: 0 - name: Setup Python environment uses: actions/setup-python@v5 with: python-version: '3.9.14' - name: Run tests run: | python src/main/scripts/process_dashboard_test.py ================================================ FILE: .github/workflows/release-charts.yaml ================================================ name: Release Helm Charts on: workflow_dispatch: jobs: release: runs-on: ubuntu-24.04 permissions: id-token: write contents: write pull-requests: write env: GH_TOKEN: ${{ secrets.GITHUB_TOKEN }} HELM_SIGNING_KEY_ID: ${{ secrets.HELM_SIGNING_KEY_ID }} GITHUB_REPOSITORY: ${GITHUB_REPOSITORY} steps: - name: Checkout uses: actions/checkout@v4 with: fetch-depth: 0 - name: Configure Git run: | git config user.name "$GITHUB_ACTOR" git config user.email "$GITHUB_ACTOR@users.noreply.github.com" - name: Install Helm uses: azure/setup-helm@v3 with: version: v3.15.3 - name: Setup Python environment uses: actions/setup-python@v5 with: python-version: '3.9.14' - name: Install Python dependencies run: | python -m pip install --upgrade pip gitpython ruamel_yaml - name: Generate Release Notes for GitHub Releases run: | cd src/main/scripts products=(bamboo bamboo-agent bitbucket confluence crowd jira) export REPO_PATH="${GITHUB_WORKSPACE}" export CHARTS_LOCATION="src/main/charts" for product in "${products[@]}"; do echo "[INFO]: Generating ${REPO_PATH}/${CHARTS_LOCATION}/${product}/RELEASE_NOTES.md" REL_NOTES_LIST=$(python3 -W ignore -c "import prepare_release; print (prepare_release.gen_changelog(\"${product}\", \"${REPO_PATH}\"))") python -c "list=${REL_NOTES_LIST}; print('\n'.join(list))" > "${REPO_PATH}"/"${CHARTS_LOCATION}"/"${product}"/RELEASE_NOTES.md done - name: Execute helm dependency update for bamboo chart run: helm dependency update src/main/charts/bamboo - name: Execute helm dependency update for bamboo-agent chart run: helm dependency update src/main/charts/bamboo-agent - name: Execute helm dependency update for bitbucket chart run: helm dependency update src/main/charts/bitbucket - name: Execute helm dependency update for confluence chart run: helm dependency update src/main/charts/confluence - name: Execute helm dependency update for crowd chart run: helm dependency update src/main/charts/crowd - name: Execute helm dependency update for jira chart run: helm dependency update src/main/charts/jira - name: Configure AWS Credentials uses: aws-actions/configure-aws-credentials@master with: aws-region: ${{ secrets.HELM_SIGNING_KEY_AWS_REGION }} role-to-assume: ${{ secrets.HELM_SIGNING_KEY_AWS_IAM_ROLE }} role-session-name: HelmSignSession - name: Get Helm Signing Key run: | 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 gpg --import helm_key gpg --export > ~/.gnupg/pubring.gpg gpg --export-secret-keys > ~/.gnupg/secring.gpg gpg --output src/main/scripts/helm_key.pub --export ${{ secrets.HELM_SIGNING_KEY_EMAIL }} - name: Release Helm Charts run: | src/main/scripts/generate_chart_repo.sh ${GH_TOKEN} - name: Commit and push index.yaml run: | git checkout -b update-index-yaml-${GITHUB_RUN_ID} git commit -m "Update index.yaml post release" git push origin update-index-yaml-${GITHUB_RUN_ID} gh pr create --title "Update index.yaml" --body "Update index.yaml after release" --base main --head update-index-yaml-${GITHUB_RUN_ID} - name: Upload Public Key To Release Assets run: | cd src/main/scripts 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"])') ./github_asset_uploader.sh ${RELEASE_VERSION} - name: Cleanup if: always() run: | rm -rf ~/.gnupg || true rm -rf helm_key ================================================ FILE: .github/workflows/release-unit-tests.yaml ================================================ name: Release Script Unit Testing on: push: paths: - 'src/main/scripts/prepare_*' workflow_dispatch: jobs: run-release-unit-tests: runs-on: ubuntu-24.04 steps: - name: Checkout code uses: actions/checkout@v4 with: fetch-depth: 0 - name: Setup Python environment uses: actions/setup-python@v5 with: python-version: '3.9.14' - name: Install Python dependencies run: | python -m pip install --upgrade pip gitpython ruamel_yaml - name: Run release unit tests run: | python src/main/scripts/prepare_release_test.py ================================================ FILE: .github/workflows/sync-grafana-dashboards.yaml ================================================ name: Update Grafana Dashboards on: schedule: - cron: '0 1 * * SUN' # At 1AM on every Sunday workflow_dispatch: jobs: sync_dashboards: runs-on: ubuntu-24.04 env: GH_TOKEN: ${{ secrets.GITHUB_TOKEN }} steps: - name: Checkout uses: actions/checkout@v4 with: fetch-depth: 0 - name: Setup Python environment uses: actions/setup-python@v5 with: python-version: '3.9.14' - name: Configure Git run: | git config user.name "$GITHUB_ACTOR" git config user.email "$GITHUB_ACTOR@users.noreply.github.com" - name: Process Grafana Dashboards run: | src/main/scripts/update_grafana_dashboards.sh - name: Commit changes and raise a PR run: | CHANGES=$(git status --porcelain=v1 2>/dev/null | wc -l) if [ ${CHANGES} -ne 0 ]; then OPEN_PRS=$(gh pr list --state open | grep "Update Grafana Dashboards for DC apps" || true) if [[ ${OPEN_PRS} ]]; then echo "Not raising PR because there are open PRs to update dashboards. Merge or close them to let the workflow raise new PRs" else git checkout -b update-grafana-dashboards-${GITHUB_RUN_ID} git add -A git commit -m "Update Grafana dashboards for DC apps" git push origin update-grafana-dashboards-${GITHUB_RUN_ID} 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} fi else echo "All Helm charts have up to date Grafana dashboards" fi ================================================ FILE: .github/workflows/update-lts-tags.yaml ================================================ name: Update LTS Tags on: workflow_dispatch: schedule: - cron: '0 0 * * SUN' # At 00:00 on every Sunday jobs: lts_check: runs-on: ubuntu-24.04 env: ARTIFACTORY_BOT_USERNAME: "${{ secrets.ARTIFACTORY_BOT_USERNAME }}" ARTIFACTORY_BOT_PASSWORD: "${{ secrets.ARTIFACTORY_BOT_PASSWORD }}" GH_TOKEN: ${{ secrets.GITHUB_TOKEN }} steps: - name: Checkout uses: actions/checkout@v4 with: fetch-depth: 0 - name: Setup Python environment uses: actions/setup-python@v5 with: python-version: '3.9.14' - name: Install dependencies run: | python -m pip install --upgrade pip pip install pyyaml requests - name: Install Helm Docs uses: envoy/install-helm-docs@v1.0.0 with: version: 1.12.0 - name: Configure Git run: | git config user.name "$GITHUB_ACTOR" git config user.email "$GITHUB_ACTOR@users.noreply.github.com" - name: Update LTS tags in Helm charts run: | cd src/test/scripts python update_versions.py - name: Update README files with helm-docs run: | cd src/main/charts helm-docs - name: Commit changes and raise a PR run: | CHANGES=$(git status --porcelain=v1 2>/dev/null | wc -l) if [ ${CHANGES} -ne 0 ]; then OPEN_PRS=$(gh pr list --state open | grep "Update appVersions for DC apps" || true) if [[ ${OPEN_PRS} ]]; then echo "Not raising PR because there are open PRs to upgrade versions. Merge or close them to let the workflow raise new PRs" else git checkout -b lts-tag-update-${GITHUB_RUN_ID} git add -A git commit -m "Update appVersions for DC apps" git push origin lts-tag-update-${GITHUB_RUN_ID} 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} fi else echo "All Helm charts have the latest LTS appVersion" fi ================================================ FILE: .gitignore ================================================ .idea .vscode target __pycache__ *.iml \#*\# docs/site tmp .settings .project .classpath # ignore installed common library chart src/main/charts/*/charts/*.tgz # Stale tmpfile from failed release process src/main/charts/*/tmp* ================================================ FILE: .java-version ================================================ 11.0 ================================================ FILE: .pre-commit-config.yaml ================================================ repos: - repo: https://github.com/norwoodj/helm-docs rev: v1.12.0 hooks: - id: helm-docs args: - --chart-search-root=src/main/charts # Repeating the flag adds this to the list, now [./_templates.gotmpl, README.md.gotmpl] # A base filename makes it relative to each chart directory found - --template-files=./README.md.gotmpl ================================================ FILE: BREAKING_CHANGES.md ================================================ # Breaking Changes ## Version 2.0.0 ### Required values * `.Values.bitbucket.clustering.group` is required for Bitbucket * `.Values.bitbucket.mirror` is required for Bitbucket * `.Values.bitbucket.podManagementStrategy` is required for Bitbucket * `.Values.ingress.className` is required for all products ### `securityContext` format change `.Values..securityContext` is now fully configurable with standard [Kubernetes values](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/). In order to make this happen, we removed `gid` and `enabled` fields from `securityContext` stanza in `values.yaml` file. Instead, 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). #### Action required - If `.Values..securityContext.enabled` was set to `true` (the default value), set the existing `.Values..securityContext.gid` value to `.Values..securityContext.fsGroup`. - 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. #### Troubleshooting If you encounter this error: ``` Error: 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] ``` It means your `values.yaml` file contains the unsupported `enabled` or `gid` values for the `securityContext`. Please follow the steps from `securityContext` change above. ### OpenSearch Credentials in Confluence Helm Chart OpenSearch 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). In **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)). When 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. This is a one-time operation. After the upgrade, you can set `confluence.forceConfigUpdate` to false. ================================================ FILE: CODE_OF_CONDUCT.md ================================================ # Contributor Code of Conduct As 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. We 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. Examples of unacceptable behavior by participants include: * The use of sexualized language or imagery * Personal attacks * Trolling or insulting/derogatory comments * Public or private harassment * Publishing other's private information, such as physical or electronic addresses, without explicit permission * Submitting contributions or comments that you know to violate the intellectual property or privacy rights of others * Other unethical or unprofessional conduct Project 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. By 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. This Code of Conduct applies both within project spaces and in public spaces when an individual is representing the project or its community. Instances 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. This 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] [homepage]: http://contributor-covenant.org [version]: http://contributor-covenant.org/version/1/3/0/ ================================================ FILE: CONTRIBUTING.md ================================================ # Contributing to Data Center Helm Charts Thank you for considering a contribution to Data Center Helm Charts. Pull requests, issues and comments are welcome. For pull requests, please: * Add tests for new features and bug fixes * Follow the existing style * Separate unrelated changes into multiple pull requests Follow the [development setup](DEVELOPMENT.md). See the existing issues for things to start contributing. For bigger changes, please make sure you start a discussion first by creating an issue and explaining the intended change. Atlassian 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). Prior 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. * [CLA for corporate contributors](https://opensource.atlassian.com/corporate) * [CLA for individuals](https://opensource.atlassian.com/individual) ## Code Owners' Responsibilities For 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. For external contributions, any Github action workflow related changes are not acceptable. ## Windows Users This repository uses **symlinks** to share common Helm templates across product charts (see `src/main/common_templates/`). Git on Windows doesn't enable symlinks by default — without them, Helm template rendering will fail. To enable symlinks on Windows: 1. Enable **Developer Mode** in Windows Settings (Settings → Update & Security → For Developers), or run Git as Administrator 2. Configure Git to create real symlinks: ``` git config --global core.symlinks true ``` 3. Re-clone the repository after changing this setting (existing clones won't retroactively fix symlinks) ### How to run E2E tests The 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). ================================================ FILE: DEVELOPMENT.md ================================================ # Development ## Chart dependencies Product charts are using a common library chart (`common`). To download the dependency, you are required to run: ```bash for d in ./src/main/charts/*/ ; do (cd $d && helm dependency update); done ``` ## Pre-commit hooks Repository contains repository hook definition to auto-generate chart documentation in case there is a change to `values.yaml` file. ### Installation 1. Install `pre-commit` following [official instructions](https://pre-commit.com/#install). 2. In the repository root run `pre-commit install`, which will install the hooks. ### Usage When 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. # Technical documentation ## Setup Technical documentation is produced by `mkdocs` python library. The documentation and necessary files are located in `/docs/` folder. ## How to work with documentation To make working with the documentation easier, there is a `Makefile` in the project root folder. To start the server just run: make docs This 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. ## Deployment Documentation 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. ================================================ FILE: LICENSE ================================================ Apache License Version 2.0, January 2004 http://www.apache.org/licenses/ TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION 1. Definitions. "License" shall mean the terms and conditions for use, reproduction, and distribution as defined by Sections 1 through 9 of this document. "Licensor" shall mean the copyright owner or entity authorized by the copyright owner that is granting the License. "Legal Entity" shall mean the union of the acting entity and all other entities that control, are controlled by, or are under common control with that entity. For the purposes of this definition, "control" means (i) the power, direct or indirect, to cause the direction or management of such entity, whether by contract or otherwise, or (ii) ownership of fifty percent (50%) or more of the outstanding shares, or (iii) beneficial ownership of such entity. "You" (or "Your") shall mean an individual or Legal Entity exercising permissions granted by this License. "Source" form shall mean the preferred form for making modifications, including but not limited to software source code, documentation source, and configuration files. "Object" form shall mean any form resulting from mechanical transformation or translation of a Source form, including but not limited to compiled object code, generated documentation, and conversions to other media types. "Work" shall mean the work of authorship, whether in Source or Object form, made available under the License, as indicated by a copyright notice that is included in or attached to the work (an example is provided in the Appendix below). "Derivative Works" shall mean any work, whether in Source or Object form, that is based on (or derived from) the Work and for which the editorial revisions, annotations, elaborations, or other modifications represent, as a whole, an original work of authorship. For the purposes of this License, Derivative Works shall not include works that remain separable from, or merely link (or bind by name) to the interfaces of, the Work and Derivative Works thereof. "Contribution" shall mean any work of authorship, including the original version of the Work and any modifications or additions to that Work or Derivative Works thereof, that is intentionally submitted to Licensor for inclusion in the Work by the copyright owner or by an individual or Legal Entity authorized to submit on behalf of the copyright owner. For the purposes of this definition, "submitted" means any form of electronic, verbal, or written communication sent to the Licensor or its representatives, including but not limited to communication on electronic mailing lists, source code control systems, and issue tracking systems that are managed by, or on behalf of, the Licensor for the purpose of discussing and improving the Work, but excluding communication that is conspicuously marked or otherwise designated in writing by the copyright owner as "Not a Contribution." "Contributor" shall mean Licensor and any individual or Legal Entity on behalf of whom a Contribution has been received by Licensor and subsequently incorporated within the Work. 2. Grant of Copyright License. Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare Derivative Works of, publicly display, publicly perform, sublicense, and distribute the Work and such Derivative Works in Source or Object form. 3. Grant of Patent License. Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as stated in this section) patent license to make, have made, use, offer to sell, sell, import, and otherwise transfer the Work, where such license applies only to those patent claims licensable by such Contributor that are necessarily infringed by their Contribution(s) alone or by combination of their Contribution(s) with the Work to which such Contribution(s) was submitted. If You institute patent litigation against any entity (including a cross-claim or counterclaim in a lawsuit) alleging that the Work or a Contribution incorporated within the Work constitutes direct or contributory patent infringement, then any patent licenses granted to You under this License for that Work shall terminate as of the date such litigation is filed. 4. Redistribution. You may reproduce and distribute copies of the Work or Derivative Works thereof in any medium, with or without modifications, and in Source or Object form, provided that You meet the following conditions: (a) You must give any other recipients of the Work or Derivative Works a copy of this License; and (b) You must cause any modified files to carry prominent notices stating that You changed the files; and (c) You must retain, in the Source form of any Derivative Works that You distribute, all copyright, patent, trademark, and attribution notices from the Source form of the Work, excluding those notices that do not pertain to any part of the Derivative Works; and (d) If the Work includes a "NOTICE" text file as part of its distribution, then any Derivative Works that You distribute must include a readable copy of the attribution notices contained within such NOTICE file, excluding those notices that do not pertain to any part of the Derivative Works, in at least one of the following places: within a NOTICE text file distributed as part of the Derivative Works; within the Source form or documentation, if provided along with the Derivative Works; or, within a display generated by the Derivative Works, if and wherever such third-party notices normally appear. The contents of the NOTICE file are for informational purposes only and do not modify the License. You may add Your own attribution notices within Derivative Works that You distribute, alongside or as an addendum to the NOTICE text from the Work, provided that such additional attribution notices cannot be construed as modifying the License. You may add Your own copyright statement to Your modifications and may provide additional or different license terms and conditions for use, reproduction, or distribution of Your modifications, or for any such Derivative Works as a whole, provided Your use, reproduction, and distribution of the Work otherwise complies with the conditions stated in this License. 5. Submission of Contributions. Unless You explicitly state otherwise, any Contribution intentionally submitted for inclusion in the Work by You to the Licensor shall be under the terms and conditions of this License, without any additional terms or conditions. Notwithstanding the above, nothing herein shall supersede or modify the terms of any separate license agreement you may have executed with Licensor regarding such Contributions. 6. Trademarks. This License does not grant permission to use the trade names, trademarks, service marks, or product names of the Licensor, except as required for reasonable and customary use in describing the origin of the Work and reproducing the content of the NOTICE file. 7. Disclaimer of Warranty. Unless required by applicable law or agreed to in writing, Licensor provides the Work (and each Contributor provides its Contributions) on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. You are solely responsible for determining the appropriateness of using or redistributing the Work and assume any risks associated with Your exercise of permissions under this License. 8. Limitation of Liability. In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall any Contributor be liable to You for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising as a result of this License or out of the use or inability to use the Work (including but not limited to damages for loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses), even if such Contributor has been advised of the possibility of such damages. 9. Accepting Warranty or Additional Liability. While redistributing the Work or Derivative Works thereof, You may choose to offer, and charge a fee for, acceptance of support, warranty, indemnity, or other liability obligations and/or rights consistent with this License. However, in accepting such obligations, You may act only on Your own behalf and on Your sole responsibility, not on behalf of any other Contributor, and only if You agree to indemnify, defend, and hold each Contributor harmless for any liability incurred by, or claims asserted against, such Contributor by reason of your accepting any such warranty or additional liability. END OF TERMS AND CONDITIONS APPENDIX: How to apply the Apache License to your work. To apply the Apache License to your work, attach the following boilerplate notice, with the fields enclosed by brackets "[]" replaced with your own identifying information. (Don't include the brackets!) The text should be enclosed in the appropriate comment syntax for the file format. We also recommend that a file or class name and description of purpose be included on the same "printed page" as the copyright notice for easier identification within third-party archives. Copyright [2020] to [2021] Atlassian Pty Ltd Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. ================================================ FILE: Makefile ================================================ .PHONY: help doc-docker doc-build doc-serve help: @echo "Atlassian DC helm charts" @echo "" @echo "Commands:" @echo "docs - starts live server with documentation" .DEFAULT_GOAL := help doc-docker: @docker build -t squidfunk/mkdocs-material docs/build/ doc-build: @docker run --rm -it -v ${PWD}/docs:/docs squidfunk/mkdocs-material build doc-serve: @docker run --rm -it -p 8000:8000 -v ${PWD}/docs:/docs squidfunk/mkdocs-material docs: doc-docker doc-serve ================================================ FILE: README.md ================================================ # Atlassian Data Center Helm Charts [![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) [![Atlassian license](https://img.shields.io/badge/license-Apache%202.0-blue.svg?style=flat-square)](LICENSE) [![PRs Welcome](https://img.shields.io/badge/PRs-welcome-brightgreen.svg?style=flat-square)](CONTRIBUTING.md) [![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) This 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. Use 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. ## Get started **Get started right now using our [documentation](https://atlassian.github.io/data-center-helm-charts/).** We provide extensive documentation to support our Helm charts. This includes prerequisites, set up, installation, examples, and more. ## Support disclaimer We **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. ## Feedback If 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). ## Contributions Contributions are welcome. [Find out how to contribute](CONTRIBUTING.md). ## License Copyright (c) [2020] to [2021] Atlassian and others. Apache 2.0 licensed, see [license file](LICENSE). ================================================ FILE: cr.yaml ================================================ pages-branch: gh-pages index-path: docs/docs/index.yaml ================================================ FILE: docs/build/Dockerfile ================================================ FROM squidfunk/mkdocs-material RUN pip install mkdocs-awesome-pages-plugin ================================================ FILE: docs/docs/.pages ================================================ nav: - Home: README.md - User guide: userguide - Examples: examples - Troubleshooting: troubleshooting - Platforms: platforms - Containers: containers ================================================ FILE: docs/docs/README.md ================================================ # Atlassian Data Center Helm Charts [![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) [![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) [![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) [![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) This 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. Use 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. ## Support disclaimer !!! warning "Support Disclaimer" 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. 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. 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. Read more about [what we support and what we don’t](troubleshooting/SUPPORT_BOUNDARIES.md). **Certain product limitations listed below:** * **Jira** currently has [limitations with scaling](troubleshooting/LIMITATIONS.md#jira-and-horizontal-scaling). * **Bamboo** has a number of limitations, [particularly with deployment and clustering](troubleshooting/LIMITATIONS.md#deployment). Read more about these [product and platform limitations](troubleshooting/LIMITATIONS.md). ## Architecture The diagram below provides a high level overview of what a typical deployment might look like when using the Atlassian Data Center Helm charts: ![architecture](assets/images/KubernetesOverview.png "Request routing via Ingress") ## Installing the Helm charts * [Prerequisites and setup](userguide/PREREQUISITES.md) - everything you need to do before installing the Helm charts * [Verification](userguide/VERIFICATION.md) - verify the integrity of the Helm charts * [Installation](userguide/INSTALLATION.md) - the steps to install the Helm charts * [Migration](userguide/MIGRATION.md) - what you have to do if you're migrating an existing deployment to Kubernetes ## Additional content * [Operation](userguide/OPERATION.md) - how to upgrade applications, scale your cluster, and update resources * [Configuration](userguide/CONFIGURATION.md) - a deep dive into the configuration parameters * [Platforms support](platforms/PLATFORMS.md) - how to allow support for different platforms * [Examples](examples/EXAMPLES.md) - various configuration examples * [Troubleshooting](troubleshooting/TROUBLESHOOTING.md) - how to debug issues with installation ## Product versions These 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. The 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. New 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. ## Feedback If 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}. ## Contributions Contributions are welcome. [Find out how to contribute](https://github.com/atlassian/data-center-helm-charts/blob/main/CONTRIBUTING.md){.external}. ## License Apache 2.0 licensed, see [license file](https://github.com/atlassian/data-center-helm-charts/blob/main/LICENSE){.external}. ================================================ FILE: docs/docs/artifacthub-repo.yml ================================================ # Artifact Hub repository metadata file # # Some settings like the verified publisher flag or the ignored packages won't # be applied until the next time the repository is processed. Please keep in # mind that the repository won't be processed if it has not changed since the # last time it was processed. Depending on the repository kind, this is checked # in a different way. For Helm http based repositories, we consider it has # changed if the `index.yaml` file changes. For git based repositories, it does # when the hash of the last commit in the branch you set up changes. This does # NOT apply to ownership claim operations, which are processed immediately. # # https://artifacthub.io/docs/topics/repositories/#helm-charts-repositories repositoryID: 46e7e8b1-a8bb-47bf-837f-63d7ff61a463 owners: - name: abrokes-atlassian email: abrokes@atlassian.com ================================================ FILE: docs/docs/assets/images/KubernetesOverview.xml ================================================ ================================================ FILE: docs/docs/assets/images/ingress.xml ================================================ 7V1bc+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== ================================================ FILE: docs/docs/assets/stylesheets/extra.css ================================================ :root > * { --md-primary-fg-color: #0052CC; --md-primary-fg-color--light: #FFFFFF; --md-primary-fg-color--dark: #172B4D; } [data-md-color-scheme="slate"] { --md-primary-fg-color: #172B4D; --md-primary-fg-color--light: #ECB7B7; --md-primary-fg-color--dark: #091E42; --md-typeset-a-color: #4C9AFF } a[target="_blank"]::after, a.external::after { content: url("../../icons/link_external.svg"); margin: 0 2px 0 2px; vertical-align: super; } .atl-bright-color { color: #0065FF !important; } ================================================ FILE: docs/docs/containers/.pages ================================================ nav: - Jira: JIRA.md - Confluence: CONFLUENCE.md - Bitbucket: BITBUCKET.md - Bitbucket Mesh: BITBUCKET-MESH.md - Bamboo Agent: BAMBOO-AGENT.md - Bamboo: BAMBOO.md - Crowd: CROWD.md - ... ================================================ FILE: docs/docs/containers/BAMBOO-AGENT.md ================================================ # ![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 ## Overview A Bamboo Agent is a service that can run job builds. Each agent has a defined set of capabilities and can run builds only for jobs whose requirements match the agent's capabilities. If you are looking for **Bamboo Docker Image** it can be found [here](https://hub.docker.com/r/atlassian/bamboo/). To learn more about Bamboo, see: This Docker container makes it easy to get a Bamboo Remote Agent up and running. It is intended to be used as a base to build from, and as such contains limited built-in capabilities: * JDK 11, JDK 17 (from v9.4.0), JDK 21 (from v10.1.0) * Git & Git LFS * Maven 3 * Python 3 Using this image as a base, you can create a custom remote agent image with your desired build tools installed. Note that Bamboo Agent Docker Image does not include a Bamboo server. **Use docker version >= 20.10.9.** ## Quick Start For 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. To get started you can use a data volume, or named volumes. In this example we'll use named volumes. Run an Agent: ```shell docker volume create --name bambooAgentVolume docker 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 ``` !!! success "The Bamboo remote agent is now available to be approved in your Bamboo administration." ### Verbose container entrypoint logging During the startup process of the container, various operations and checks are performed to ensure that the application is configured correctly and ready to run. To help in troubleshooting and to provide transparency into this process, you can enable verbose logging. The `VERBOSE_LOGS` environment variable enables detailed debug messages to the container's log, offering insights into the actions performed by the entrypoint script. * `VERBOSE_LOGS` (default: false) Set to `true` to enable detailed debug messages during the container initialization. ## Configuration * `BAMBOO_SERVER` (required) The URL of the Bamboo Server the remote agent should connect to, e.g. `http://bamboo.mycompany.com/agentServer/` * `SECURITY_TOKEN` (default: NONE) If security token verification is enabled, this value specifies the token required to authenticate to the Bamboo server * `WRAPPER_JAVA_INITMEMORY` (default: 256) The minimum heap size of the JVM. This value is in MB and should be specified as an integer * `WRAPPER_JAVA_MAXMEMORY` (default: 512) The maximum heap size of the JVM. This value is in MB and should be specified as an integer * `IGNORE_SERVER_CERT_NAME` (default: false) Ignore SSL certificate hostname if it's issued to a different host than the one under your Bamboo Base URL hostname * `ALLOW_EMPTY_ARTIFACTS` (default: false) Allow empty directories to be published as artifacts * `BAMBOO_AGENT_PERMISSIVE_READINESS` (default: unset/false) If set to 'true', the readiness probe will be more permissive and not expect the agent to be fully configured, only that the startup wrapper is running. This is primarily intended for use when deploying agents into environments where the server may not yet be configured. * `BAMBOO_AGENT_CLASSPATH_DIR` (default: NONE) If set, agent startup process will copy agent classpath from designated location instead of downloading it from the server. This can speed up the process and reduce the load on the Bamboo server. ### Dedicated agent specific configuration * `AGENT_EPHEMERAL_FOR_KEY` (default: NONE) The value specifies the purpose for spawning the agent. It needs to be a valid ResultKey. * `KUBE_NUM_EXTRA_CONTAINERS` (default: 0) 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. * `EXTRA_CONTAINERS_REGISTRATION_DIRECTORY` (default: /pbc/kube) 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. ### Ephemeral agent specific configuration * `BAMBOO_EPHEMERAL_AGENT_DATA` (default: NONE) 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` ### Additional agent wrapper properties * `BAMBOO_WRAPPER_JAVA_ADDITIONAL_PROPERTIES` (default: NONE) 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` ## Extending base image This 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. Example of extending the agent base image by Maven and Git: ```Dockerfile FROM atlassian/bamboo-agent-base:9.6.8 USER root RUN apt-get update && \ apt-get install maven -y && \ apt-get install git -y USER ${BAMBOO_USER} RUN /bamboo-update-capability.sh "system.builder.mvn3.Maven 3.3" /usr/share/maven RUN /bamboo-update-capability.sh "system.git.executable" /usr/bin/git ``` ## Building your own image * Clone the Atlassian repository at * Modify or replace the [Jinja](https://jinja.palletsprojects.com/) templates under `config`; _NOTE_: The files must have the `.j2` extensions. However you don't have to use template variables if you don't wish. * 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 .` * Optionally push to a registry, and deploy. ## Issue tracker * You can view know issues [here](https://jira.atlassian.com/projects/BAM/issues/filter=allissues). * Please contact our support if you encounter any problems with this Dockerfile. ## Supported JDK versions and base images Bamboo Docker images are based on JDK 11, JDK 17 (from Bamboo 9.4), and JDK 21 (from Bamboo 10.1) and generated from the [official Eclipse Temurin OpenJDK Docker images](https://hub.docker.com/_/eclipse-temurin) and [Red Hat Universal Base Images](https://catalog.redhat.com/software/containers/ubi9/openjdk-17/61ee7c26ed74b2ffb22b07f6?architecture=amd64). Starting in Bamboo 9.4, UBI tags are available in 2 formats: `-ubi9`, `-ubi9-jdk17`, or `-ubi9-jdk21>` The Docker images follow the [Atlassian Support end-of-life policy](https://confluence.atlassian.com/support/atlassian-support-end-of-life-policy-201851003.html); images for unsupported versions of the products remain available but will no longer receive updates or fixes. However, Bamboo is an exception to this. Due to the need to support JDK 11 and Kubernetes, we currently only generate new images for Bamboo 9.1 and up. Legacy builds for JDK 8 are still available in Docker Hub, and building custom images is available (see above). Historically, we have also generated other versions of the images, including JDK 8, Alpine, and 'slim' versions of the JDK. These legacy images still exist in Docker Hub, however they should be considered deprecated, and do not receive updates or fixes. If for some reason you need a different version, see "Building your own image". ## Migration to UBI If 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). Also, 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). ## Supported architectures Currently, the Atlassian Docker images are built for the `linux/amd64` and `linux/arm64` target platforms; we do not have other architectures on our roadmap at this point. However, the Dockerfiles and support tooling have now had all architecture-specific components removed, so if necessary it is possible to build images for any platform supported by Docker. ### Building on the target architecture The simplest method of getting a platform image is to build it on a target machine; and specify either `linux/amd64` or `linux/arm64`. See [Building your own image](#building-your-own-image) above. Note: This method is known to work on Mac M1 and AWS ARM64 machines, but has not been extensively tested. ## Support For product support, go to You can also visit the [Atlassian Data Center](https://community.atlassian.com/t5/Atlassian-Data-Center-on/gh-p/DC_Kubernetes) forum for discussion on running Atlassian Data Center products in containers. ================================================ FILE: docs/docs/containers/BAMBOO.md ================================================ # ![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 !!! warning "Server image deprecation" This Docker image has been published as both `atlassian/bamboo` and `atlassian/bamboo-server` up until February 15, 2024. Both names refer to the same image. However, post-February 15, 2024, the `atlassian/bamboo-server` version ceased receiving updates, including both existing and new tags. If you have been using `atlassian/bamboo-server`, switch to the `atlassian/bamboo` image to ensure access to the latest updates and new tags. ## Overview Bamboo is a continuous integration and deployment tool that ties automated builds, tests and releases together in a single workflow. Learn more about Bamboo: This Docker container makes it easy to get an instance of Bamboo up and running. **Use docker version >= 20.10.10** ## Quick Start For the `BAMBOO_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. Additionally, if running Bamboo in Data Center mode it is required that a shared filesystem is mounted. To get started you can use a data volume, or named volumes. In this example we'll use named volumes. ```shell docker volume create --name bambooVolume docker run -v bambooVolume:/var/atlassian/application-data/bamboo --name="bamboo" -d -p 8085:8085 -p 54663:54663 atlassian/bamboo ``` !!! success "Bamboo is now available on ." Please ensure your container has the necessary resources allocated to it. We recommend 2GiB of memory allocated to accommodate the application server. See [System Requirements](https://confluence.atlassian.com/display/BAMBOO/Bamboo+Best+Practice+-+System+Requirements) for further information. !!! tip "If you are using `docker-machine` on Mac OS X, please use `open http://$(docker-machine ip default):8085` instead." ## Common settings ### Verbose container entrypoint logging During the startup process of the container, various operations and checks are performed to ensure that the application is configured correctly and ready to run. To help in troubleshooting and to provide transparency into this process, you can enable verbose logging. The `VERBOSE_LOGS` environment variable enables detailed debug messages to the container's log, offering insights into the actions performed by the entrypoint script. * `VERBOSE_LOGS` (default: false) Set to `true` to enable detailed debug messages during the container initialization. ### Memory / Heap Size If 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. * `JVM_MINIMUM_MEMORY` (default: 512m) The minimum heap size of the JVM * `JVM_MAXIMUM_MEMORY` (default: 1024m) The maximum heap size of the JVM ### Tomcat and Reverse Proxy Settings If Bamboo is run behind a reverse proxy server as [described here](https://confluence.atlassian.com/kb/integrating-apache-http-server-reverse-proxy-with-bamboo-753894403.html), then you need to specify extra options to make Bamboo aware of the setup. They can be controlled via the below environment variables. * `ATL_PROXY_NAME` (default: NONE) The reverse proxy's fully qualified hostname. `CATALINA_CONNECTOR_PROXYNAME` is also supported for backwards compatibility. * `ATL_PROXY_PORT` (default: NONE) The reverse proxy's port number via which Bamboo is accessed. `CATALINA_CONNECTOR_PROXYPORT` is also supported for backwards compatibility. * `ATL_TOMCAT_PORT` (default: 8085) The port for Tomcat/Bamboo to listen on. Depending on your container deployment method this port may need to be [exposed and published][docker-expose]. * `ATL_TOMCAT_PROTOCOL` (default: HTTP/1.1) The protocol to be used by Tomcat. Bamboo provides additional customized protocols that will support encryption along with `ATL_TOMCAT_BAMBOO_ENCRYPTION_KEY`. For more information, see [Encrypting passwords in server][encrypting-passwords-in-server]. * `ATL_TOMCAT_SCHEME` (default: http) The protocol via which the application is accessed. `CATALINA_CONNECTOR_SCHEME` is also supported for backwards compatibility. * `ATL_TOMCAT_SECURE` (default: false) Set 'true' if `ATL_TOMCAT_SCHEME` is 'https'. `CATALINA_CONNECTOR_SECURE` is also supported for backwards compatibility. * `ATL_TOMCAT_CONTEXTPATH` (default: NONE) The context path the application is served over. `CATALINA_CONTEXT_PATH` is also supported for backwards compatibility. The following Tomcat/Catalina options are also supported. For more information, see . * `ATL_TOMCAT_ACCEPTCOUNT` (default: 100) * `ATL_TOMCAT_CONNECTIONTIMEOUT` (default: 20000) * `ATL_TOMCAT_ENABLELOOKUPS` (default: false) * `ATL_TOMCAT_MAXHTTPHEADERSIZE` (default: 8192) * `ATL_TOMCAT_MAXTHREADS` (default: 150) * `ATL_TOMCAT_MGMT_PORT` (default: 8007) * `ATL_TOMCAT_MINSPARETHREADS` (default: 25) * `ATL_TOMCAT_URIENCODING` (default: UTF-8) * `ATL_TOMCAT_STUCKTHREADDETECTIONVALVE_THRESHOLD` (default: 60) The standard HTTP connectors (NIO, NIO2 and APR/native) settings * `ATL_TOMCAT_ADDRESS` For servers with more than one IP address, this attribute specifies which address will be used for listening on the specified port. * `ATL_TOMCAT_SECRET` (default: null) Only requests from workers with this secret keyword will be accepted. The default value is null. This attribute must be specified with a non-null, non-zero length value unless secretRequired is explicitly configured to be false. If this attribute is configured with a non-null, non-zero length value then the workers must provide a matching value else the request will be rejected irrespective of the setting of secretRequired. * `ATL_TOMCAT_SECRET_REQUIRED` (default: false) If this attribute is true, the AJP Connector will only start if the secret attribute is configured with a non-null, non-zero length value. This attribute only controls whether the secret attribute is required to be specified for the AJP Connector to start. It does not control whether workers are required to provide the secret. The default value is true. This attribute should only be set to false when the Connector is used on a trusted network. * `ATL_TOMCAT_BAMBOO_ENCRYPTION_KEY` File which contains encryption key used for Bamboo-specific connectors. * `ATL_TOMCAT_SSL_ENABLED` Set this attribute to `true` to enable SSL traffic on a connector. * `ATL_TOMCAT_SSL_PROTOCOL` JSSE only. The SSL protocol(s) to use (a single value may enable multiple protocols - see the JVM documentation for details). * `ATL_TOMCAT_SSL_CERTIFICATE_FILE` Name of the file that contains the server certificate. The format is PEM-encoded. Relative paths will be resolved against $CATALINA_BASE. * `ATL_TOMCAT_SSL_CERTIFICATE_KEY_FILE` Name of the file that contains the server private key. The format is PEM-encoded. The default value is the value of certificateFile and in this case both certificate and private key have to be in this file (NOT RECOMMENDED). Relative paths will be resolved against $CATALINA_BASE. * `ATL_TOMCAT_SSL_PASS` The password used to access the private key associated with the server certificate from the specified file. * `ATL_TOMCAT_KEYSTORE_FILE` JSSE only. The pathname of the keystore file where you have stored the server certificate and key to be loaded. By default, the pathname is the file .keystore in the operating system home directory of the user that is running Tomcat. * `ATL_TOMCAT_KEYSTORE_PASS` JSSE only. The password to use to access the keystore containing the server's private key and certificate. If not specified, a default of _changeit_ will be used. * `ATL_TOMCAT_KEY_PASS` The password used to access the private key associated with the server certificate from the specified file. * `ATL_TOMCAT_KEY_ALIAS` Specify the key alias to be loaded in case the provided keystore contains multiple private key aliases. * `ATL_TOMCAT_CLIENT_AUTH` Set to required if you want the SSL stack to require a valid certificate chain from the client before accepting a connection. Set to optional if you want the SSL stack to request a client Certificate, but not fail if one isn't presented. Set to optionalNoCA if you want client certificates to be optional and you don't want Tomcat to check them against the list of trusted CAs. If the TLS provider doesn't support this option (OpenSSL does, JSSE does not) it is treated as if optional was specified. A none value (which is the default) will not require a certificate chain unless the client requests a resource protected by a security constraint that uses CLIENT-CERT authentication. * `ATL_TOMCAT_TRUSTSTORE_FILE` JSSE only. The trust store file to use to validate client certificates. The default is the value of the javax.net.ssl.trustStore system property. If neither this attribute nor the default system property is set, no trust store will be configured. Relative paths will be resolved against $CATALINA_BASE. A URL may also be used for this attribute. * `ATL_TOMCAT_TRUSTSTORE_PASS` JSSE only. The password to access the trust store. The default is the value of the javax.net.ssl.trustStorePassword system property. If that property is null, no trust store password will be configured. If an invalid trust store password is specified, a warning will be logged and an attempt will be made to access the trust store without a password which will skip validation of the trust store contents. * `ATL_TOMCAT_COMPRESSION` Enables HTTP compression. The acceptable values for the parameter are: * `off` or `0` - disabled compression * `on` - enabled compression * `force` - forces compression in all cases * `numerical integer value`, e.g. `100` - which is equivalent to `on`, but specifies the minimum amount of data before the output is compressed. If the content length is not known and compression is set to `on` or more aggressive, the output will also be compressed. If not specified, compression will remain disabled. * `ATL_TOMCAT_COMPRESSIBLEMIMETYPE` A comma-separated list of MIME types for which HTTP compression may be used. Only applicable if `ATL_TOMCAT_COMPRESSION` is set to `on` or `force`. If not specified, this attribute defaults to `text/html,text/xml,text/plain,text/css,text/javascript,application/javascript,application/json,application/xml`. * `ATL_TOMCAT_COMPRESSIONMINSIZE` The minimum amount of data before the output is compressed. Only applicable if `ATL_TOMCAT_COMPRESSION` is set to `on` or `force`. If not specified, this attribute defaults to `2048`. * `ATL_TOMCAT_REQUESTATTRIBUTESENABLED` Checks for the existence of request attributes (typically set by the RemoteIpValve and similar) that should be used to override the values returned by the request for remote address, remote host, server port and protocol. This property is usually combined with `ATL_TOMCAT_TRUSTEDPROXIES` and `ATL_TOMCAT_INTERNALPROXIES` to show IP address of the remote host instead of the load balancer's. If not declared, the default value of `false` will be used. * `ATL_TOMCAT_TRUSTEDPROXIES` A list of IP addresses separated by a pipe character e.g. `10.0.9.6|10.0.9.32`. Trusted proxies that appear in the `remoteIpHeader` will be trusted and *will appear* in the `proxiesHeader` value. By adding a list of Trusted Proxies, Bamboo will remove the load balancers' IP addresses from Bamboo's view of the incoming connection. This could be desired in a clustered load balancer architecture where the load balancer address changes depending on which node proxies the connection, requiring re-approval of Agents. If not specified, no trusted proxies will be trusted. * `ATL_TOMCAT_INTERNALPROXIES` A list of IP addresses separated by a pipe character e.g. `10.0.9.6|10.0.9.32`. Trusted proxies that appear in the `remoteIpHeader` will be trusted and *will not appear* in the `proxiesHeader` value. By adding a list of Internal Proxies, Bamboo will remove the load balancers' IP addresses from Bamboo's view of the incoming connection. This could be desired in a clustered load balancer architecture where the load balancer address changes depending on which node proxies the connection, requiring re-approval of Agents. If not specified, no internal proxies will be trusted. ### Access Log Settings You 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. * `ATL_TOMCAT_ACCESS_LOGS_MAXDAYS` (default: -1) ### JVM configuration If you need to pass additional JVM arguments to Bamboo, such as specifying a custom trust store, you can add them via the below environment variable * `JVM_SUPPORT_RECOMMENDED_ARGS` Additional JVM arguments for Bamboo. ??? example `docker run -e JVM_SUPPORT_RECOMMENDED_ARGS=-Djavax.net.ssl.trustStore=/var/atlassian/application-data/bamboo/cacerts -v bambooVolume:/var/atlassian/application-data/bamboo --name="bamboo" -d -p 8085:8085 -p 54663:54663 atlassian/bamboo` ### Bamboo-specific settings * `ATL_AUTOLOGIN_COOKIE_AGE` (default: 1209600; two weeks, in seconds) The maximum time a user can remain logged-in with 'Remember Me'. * `BAMBOO_HOME` The Bamboo home directory. This may be on an mounted volume; if so it should be writable by the user `bamboo`. See note below about UID mappings. * `ATL_BROKER_URI` (default: nio://0.0.0.0:54663) The ActiveMQ Broker URI to listen on for in-bound remote agent communication. * `ATL_BROKER_CLIENT_URI` The ActiveMQ Broker Client URI that remote agents will use to attempt to establish a connection to the ActiveMQ Broker on the Bamboo server. * `ATL_BAMBOO_SKIP_CONFIG` (defaults to `False`) If `true` skip the generation of `bamboo.cfg.xml`. This is only really useful for Bamboo versions >= 8.1, which added environment-based configuration (see next section). #### Optional configuration pre-seeding Optionally, for new deployments, the setup flow can be skipped by provided the required values via the environment. NOTE: This only work with Bamboo versions >= 8.1. * `SECURITY_TOKEN` The security token to use for server/agent authentication. Additional details [are available here](https://confluence.atlassian.com/bamboo/agent-authentication-289277196.html#Agentauthentication-SecuritytokenverificationSecuritytokenverification) * `ATL_BAMBOO_DISABLE_AGENT_AUTH` (default: false) Whether to disable agent authentication. Defaults to false. * `ATL_LICENSE` The licence to supply. Licenses can be generated at . * `ATL_BASE_URL` Bamboo instance Base URL. * `ATL_ADMIN_USERNAME` * `ATL_ADMIN_PASSWORD` * `ATL_ADMIN_FULLNAME` * `ATL_ADMIN_EMAIL` The admin details and credentials. * `ATL_IMPORT_OPTION` Import data from backup file during setup. Default value is 'clean' which skip import step and create Bamboo home from scratch. If value is 'import' then `ATL_IMPORT_PATH` should contain path to backup archive. * `ATL_IMPORT_PATH` Full path to backup archive. ### Database configuration It is optionally possible to configure the database from the environment, which will pre-fill it for the installation wizard. The password cannot be pre-filled. The following variables are all must all be supplied if using this feature: * `ATL_JDBC_URL` The database URL; this is database-specific. * `ATL_JDBC_USER` The database user to connect as. * `ATL_JDBC_PASSWORD` The database user password to connect with. * `ATL_DB_TYPE` The type of database; valid supported values are: * `h2` - for evaluation needs only * `mssql` * `mysql` * `oracle` * `postgresql` ???+ note "MySQL or Oracle JDBC drivers" Due to licensing restrictions Bamboo does not ship with a MySQL or Oracle JDBC drivers (since Bamboo 7.0). To use these databases you will need to copy a suitable driver into the container and restart it. For example, to copy the MySQL driver into a container named "bamboo", you would do the following: `docker cp mysql-connector-java.x.y.z.jar bambooo:/opt/atlassian/bamboo/lib` `docker restart bamboo` #### Optional database settings The following variables are for the database connection pool, and are optional. * `ATL_DB_POOLMINSIZE` (default: 3) * `ATL_DB_POOLMAXSIZE` (default: 170) * `ATL_DB_TIMEOUT` (default: 120000) * `ATL_DB_CONNECTIONTIMEOUT` (default: 30000) * `ATL_DB_LEAKDETECTION` (default: 0 / disabled) ### Container Configuration * `ATL_FORCE_CFG_UPDATE` (default: false) The Docker [entrypoint][entrypoint.py] generates application configuration on first start; not all of these files are regenerated on subsequent starts. This is deliberate, to avoid race conditions or overwriting manual changes during restarts and upgrades. However in deployments where configuration is purely specified through the environment (e.g. Kubernetes) this behaviour may be undesirable; this flag forces an update of all generated files. In Bamboo the affected files are: `unattended-setup.properties`, `bamboo.cfg.xml` See [the entrypoint code][entrypoint.py] for the details of how configuration files are generated. * `ATL_ALLOWLIST_SENSITIVE_ENV_VARS` 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. ???+ warning "Value exposure on host OS" When using this property, the values to sensitive environment variables will be available in clear text on the host OS. As such, this data may be exposed to users or processes running on the host OS. * `SET_PERMISSIONS` (default: true) Define whether to set home directory permissions on startup. Set to `false` to disable this behaviour. ## File system permissions and user IDs By default, the Bamboo application runs as the user `bamboo`, with a UID and GID of 2005. Bamboo this UID must have write access to the home directory filesystem. If for some reason a different UID must be used, there are a number of options available: * The Docker image can be rebuilt with a different UID. * Under Linux, the UID can be remapped using [user namespace remapping](https://docs.docker.com/engine/security/userns-remap/). ## Upgrade To 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: ```shell docker stop bamboo docker rm bamboo docker run ... (See above) ``` As your data is stored in the data volume directory on the host it will still be available after the upgrade. !!! note "Please make sure that you **don't** accidentally remove the `bamboo` container and its volumes using the `-v` option." ## Backup For 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. If 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. Read more about data recovery and backups: ## Shutdown Depending on your configuration Bamboo may take a short period to shutdown any active operations to finish before termination. If sending a `docker stop` this should be taken into account with the `--time` flag. Alternatively, the script `/shutdown-wait.sh` is provided, which will initiate a clean shutdown and wait for the process to complete. This is the recommended method for shutdown in environments which provide for orderly shutdown, e.g. Kubernetes via the `preStop` hook. ## Versioning The `latest` tag matches the most recent release of Atlassian Bamboo. Thus `atlassian/bamboo:latest` will use the newest version of Bamboo available. Alternatively you can use a specific major, major.minor, or major.minor.patch version of Bamboo by using a version number tag: * `atlassian/bamboo:9` * `atlassian/bamboo:9.6` * `atlassian/bamboo:9.6.8` All versions from 8.0+ are available. Legacy builds for older versions are available but are no longer supported. ## Supported JDK versions and base images Bamboo Docker images are based on JDK 11, JDK 17 (from Bamboo 9.4), and JDK 21 (from Bamboo 10.1) and generated from the [official Eclipse Temurin OpenJDK Docker images](https://hub.docker.com/_/eclipse-temurin) and [Red Hat Universal Base Images](https://catalog.redhat.com/software/containers/ubi9/openjdk-17/61ee7c26ed74b2ffb22b07f6?architecture=amd64). Starting in Bamboo 9.4, UBI tags are available in 2 formats: `-ubi9`, `-ubi9-jdk17`, `-ubi9-jdk21` The Docker images follow the [Atlassian Support end-of-life policy](https://confluence.atlassian.com/support/atlassian-support-end-of-life-policy-201851003.html); images for unsupported versions of the products remain available but will no longer receive updates or fixes. However, Bamboo is an exception to this. Due to the need to support JDK 11 and Kubernetes, we currently only generate new images for Bamboo 9.1 and up. Legacy builds for JDK 8 are still available in Docker Hub, and building custom images is available (see below). Historically, we have also generated other versions of the images, including JDK 8, Alpine, and 'slim' versions of the JDK. These legacy images still exist in Docker Hub, however they should be considered deprecated, and do not receive updates or fixes. If for some reason you need a different version, see "Building your own image". ## Building your own image * Clone the Atlassian repository at * Modify or replace the [Jinja](https://jinja.palletsprojects.com/) templates under `config`; _NOTE_: The files must have the `.j2` extensions. However, you don't have to use template variables if you don't wish. * 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 .` * Optionally push to a registry, and deploy. ## Migration to UBI If 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). Also, 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). ## Supported architectures Currently, the Atlassian Docker images are built for the `linux/amd64` and `linux/arm64` target platforms; we do not have other architectures on our roadmap at this point. However, the Dockerfiles and support tooling have now had all architecture-specific components removed, so if necessary it is possible to build images for any platform supported by Docker. ### Building on the target architecture The simplest method of getting a platform image is to build it on a target machine; and specify either `linux/amd64` or `linux/arm64`. See [Building your own image](#building-your-own-image) above. Note: This method is known to work on Mac M1 and AWS ARM64 machines, but has not been extensively tested. ## Troubleshooting These images include built-in scripts to assist in performing common JVM diagnostic tasks. ### Thread dumps `/opt/atlassian/support/thread-dumps.sh` can be run via `docker exec` to easily trigger the collection of thread dumps from the containerized application. For example: ```shell docker exec my_container /opt/atlassian/support/thread-dumps.sh ``` By default this script will collect 10 thread dumps at 5 second intervals. This can be overridden by passing a custom value for the count and interval, by using `-c` / `--count` and `-i` / `--interval` respectively. For example, to collect 20 thread dumps at 3 second intervals: ```shell docker exec my_container /opt/atlassian/support/thread-dumps.sh --count 20 --interval 3 ``` Thread dumps will be written to `$APP_HOME/thread_dumps/`. ???+ note "Disable capturing output from top run" By default this script will also capture output from top run in 'Thread-mode'. This can be disabled by passing `-n` / `--no-top` ### Heap dump `/opt/atlassian/support/heap-dump.sh` can be run via `docker exec` to easily trigger the collection of a heap dump from the containerized application. For example: ```shell docker exec my_container /opt/atlassian/support/heap-dump.sh ``` A heap dump will be written to `$APP_HOME/heap.bin`. If a file already exists at this location, use `-f` / `--force` to overwrite the existing heap dump file. ### Manual diagnostics The `jcmd` utility is also included in these images and can be used by starting a `bash` shell in the running container: ```shell docker exec -it my_container /bin/bash ``` ## Support For product support, go to You can also visit the [Atlassian Data Center](https://community.atlassian.com/t5/Atlassian-Data-Center-on/gh-p/DC_Kubernetes) forum for discussion on running Atlassian Data Center products in containers. ## Changelog For a detailed list of changes to the Docker image configuration see [the Git commit history](https://bitbucket.org/atlassian-docker/docker-bamboo-server/commits/). ## License Copyright © 2020 Atlassian Corporation Pty Ltd. Licensed under the Apache License, Version 2.0. [docker-expose]: https://docs.docker.com/v17.09/engine/userguide/networking/default_network/binding/ [entrypoint.py]: https://bitbucket.org/atlassian-docker/docker-bamboo-server/src/master/entrypoint.py [encrypting-passwords-in-server]: https://confluence.atlassian.com/display/BAMBOO/Encrypting+passwords+in+server.xml ================================================ FILE: docs/docs/containers/BITBUCKET-MESH.md ================================================ # ![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 ## Overview Bitbucket Data Center is an on-premises source code management solution for Git that's secure, fast, and enterprise grade. Create and manage repositories, set up fine-grained permissions, and collaborate on code - all with the flexibility of your servers. Bitbucket Mesh is an optional scalability extension for Bitbucket. For more information see . This Docker image is published as `atlassian/bitbucket-mesh`. This Docker container makes it easy to get Mesh nodes for a Bitbucket Data Center up and running. It will only work in conjunction with a Bitbucket Data Center server. For full documentation on running Bitbucket Data Center with Mesh nodes, see [the Bitbucket documentation](https://confluence.atlassian.com/bitbucketserver/bitbucket-mesh-1128304351.html). _* If running this image in a production environment, we strongly recommend you run this image using a specific version tag instead of latest. This is because the image referenced by the latest tag changes often and we cannot guarantee that it will be backwards compatible. *_ **Use docker version >= 20.10.10** ## Quick Start For the `MESH_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. Volume permissions are managed by entry scripts. To get started you can use a data volume, or named volumes. In this example we'll use named volumes. ```shell docker volume create --name bitbucketMeshVolume docker run -v bitbucketMeshVolume:/var/atlassian/application-data/mesh --name="bitbucket-mesh" -d -p 7777:7777 atlassian/bitbucket-mesh ``` Note that this command can substitute folder paths with named volumes. Please ensure your container has the necessary resources allocated to it. We recommend 2GiB of memory allocated to accommodate both the application server and the git processes. See [Supported Platforms](https://confluence.atlassian.com/display/BitbucketServer/Supported+platforms) for further information. ## Common settings ### Verbose container entrypoint logging During the startup process of the container, various operations and checks are performed to ensure that the application is configured correctly and ready to run. To help in troubleshooting and to provide transparency into this process, you can enable verbose logging. The `VERBOSE_LOGS` environment variable enables detailed debug messages to the container's log, offering insights into the actions performed by the entrypoint script. * `VERBOSE_LOGS` (default: false) Set to `true` to enable detailed debug messages during the container initialization. ### Mesh Node Configuration * `MESH_HOME` The home directory used by the Mesh node. This should have full read/write permissions and be persistent – your Bitbucket Mesh data will be stored here. * `GRPC_SERVER_PORT` (default: 7777) The port used by the Mesh node to communicate with the server. ### Mesh Node JVM Configuration If you need to override the Mesh node's default memory configuration or pass additional JVM arguments, use the environment variables below * `JVM_MINIMUM_MEMORY` (default: 512m) The minimum heap size of the JVM * `JVM_MAXIMUM_MEMORY` (default: 1024m) The maximum heap size of the JVM * `JVM_SUPPORT_RECOMMENDED_ARGS` (default: NONE) Additional JVM arguments for the Mesh node , such as a custom Java Trust Store ### JMX Monitoring JMX monitoring can be enabled with `JMX_ENABLED=true`. Information on additional settings and available metrics is available in the [Bitbucket JMX documentation](https://confluence.atlassian.com/bitbucketserver/enabling-jmx-counters-for-performance-monitoring-776640189.html). ## Other settings As well as the above settings, all settings that are available in the [mesh.properties file](https://confluence.atlassian.com/bitbucketserver/mesh-configuration-properties-1128304362.html) can also be provided via Docker environment variables. For a full explanation of converting Bitbucket properties into environment variables see [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). To translate a property name into an environment variable: * dot `.` becomes underscore `_` * dash `-` becomes underscore `_` * Example: `this.new-property` becomes `THIS_NEW_PROPERTY` ## Container Configuration * `SET_PERMISSIONS` (default: true) Define whether to set home directory permissions on startup. Set to `false` to disable this behaviour. ## Home directory and user IDs By default the Bitbucket application runs as the user `bitbucket`, with a UID and GID of 2003. If for some reason a different UID must be used, there are a number of options available: * The Docker image can be rebuilt with a different UID. * Under Linux, the UID can be remapped using [user namespace remapping](https://docs.docker.com/engine/security/userns-remap/). ## Shutdown The Mesh node allows a configurable grace period for active operations to finish before termination; by default this is 30s. If sending a `docker stop` this should be taken into account with the `--time` flag. Alternatively, the script `/shutdown-wait.sh` is provided, which will initiate a clean shutdown and wait for the process to complete. This is the recommended method for shutdown in environments which provide for orderly shutdown, e.g. Kubernetes via the `preStop` hook. ## Versioning You should ensure you are running the appropriate Mesh version for your Bitbucket Data Center server. A support matrix is available here: [Bitbucket Mesh compatibility matrix](https://confluence.atlassian.com/bitbucketserver/bitbucket-mesh-compatibility-matrix-1127254859.html). ## Supported JDK versions and base images The Bitbucket Mesh Docker images support the following JDK versions: * **JDK 11**: Supported for Mesh versions 2.0.1 to 3.0.0 * **JDK 17**: Supported for Mesh versions 2.4 to 3.4.5 * **JDK 21**: Supported for Mesh versions 3.4.5 and above (required for Mesh 4.x) Images are generated from the [official Eclipse Temurin OpenJDK Docker images](https://hub.docker.com/_/eclipse-temurin). Starting from 2.4, [UBI based](https://catalog.redhat.com/software/containers/ubi9/openjdk-17/61ee7c26ed74b2ffb22b07f6?architecture=amd64) tags are published as well. UBI tags are available in the following formats: * For JDK 17: `-ubi9` and `-ubi9-jdk17` * For JDK 21: `-ubi9` and `-ubi9-jdk21` (from version 3.4.5) The Docker images follow the [Atlassian Support end-of-life policy](https://confluence.atlassian.com/support/atlassian-support-end-of-life-policy-201851003.html); images for unsupported versions of the products remain available but will no longer receive updates or fixes. If for some reason you need a different version, see "Building your own image" ## Migration to UBI If 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`. Also, 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 * Clone the Atlassian repository at https://bitbucket.org/atlassian-docker/docker-atlassian-bitbucket-mesh/ * Modify or replace the [Jinja](https://jinja.palletsprojects.com/) templates under `config`; _NOTE_: The files must have the `.j2` extensions. However, you don't have to use template variables if you don't wish. * Build the new image with e.g: `docker build --tag my-bitbucket-mesh-image --build-arg MESH_VERSION=1.x.x .` * Optionally push to a registry, and deploy. ## Supported architectures Currently, Bitbucket Mesh container images are built for the `linux/amd64` and `linux/arm64` target platforms. The Dockerfiles and support tooling have now had all architecture-specific components removed, so if necessary it is possible to build images for any platform supported by OCI-compliant container runtimes. ## Building on the target architecture The simplest method of getting a platform image is to build it on a target machine; see "Building your own image" above. Note: This method is known to work on Mac M1 and AWS ARM64 machines, but has not be extensively tested. ## Troubleshooting These images include built-in scripts to assist in performing common JVM diagnostic tasks. ### Thread dumps `/opt/atlassian/support/thread-dumps.sh` can be run via `docker exec` to easily trigger the collection of thread dumps from the containerized application. For example: ```shell docker exec my_container /opt/atlassian/support/thread-dumps.sh ``` By default, this script will collect 10 thread dumps at 5 second intervals. This can be overridden by passing a custom value for the count and interval, by using `-c` / `--count` and `-i` / `--interval` respectively. For example, to collect 20 thread dumps at 3 second intervals: ```shell docker exec my_container /opt/atlassian/support/thread-dumps.sh --count 20 --interval 3 ``` Thread dumps will be written to `$APP_HOME/thread_dumps/`. ???+ note "Disable capturing output from top run" By default this script will also capture output from top run in 'Thread-mode'. This can be disabled by passing `-n` / `--no-top` ### Heap dump `/opt/atlassian/support/heap-dump.sh` can be run via `docker exec` to easily trigger the collection of a heap dump from the containerized application. For example: ```shell docker exec my_container /opt/atlassian/support/heap-dump.sh ``` A heap dump will be written to `$APP_HOME/heap.bin`. If a file already exists at this location, use `-f` / `--force` to overwrite the existing heap dump file. ## Manual diagnostics The `jcmd` utility is also included in these images and can be used by starting a `bash` shell in the running container: ```shell docker exec -it my_container /bin/bash ``` ## Support For product support, go to [support.atlassian.com](https://support.atlassian.com/) You can also visit the [Atlassian Data Center](https://community.atlassian.com/t5/Atlassian-Data-Center-on/gh-p/DC_Kubernetes) forum for discussion on running Atlassian Data Center products in containers. # Changelog For a detailed list of changes to the Docker image configuration see [the Git commit history](https://bitbucket.org/atlassian-docker/docker-atlassian-bitbucket-mesh/commits/). # License Copyright © 2022 Atlassian Corporation Pty Ltd. Licensed under the Apache License, Version 2.0. ================================================ FILE: docs/docs/containers/BITBUCKET.md ================================================ # ![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 !!! warning "Server image deprecation" This Docker image has been published as both `atlassian/bitbucket` and `atlassian/bitbucket-server` up until February 15, 2024. Both names refer to the same image. However, post-February 15, 2024, the `atlassian/bitbucket-server` version ceased receiving updates, including both existing and new tags. If you have been using `atlassian/bitbucket-server`, switch to the `atlassian/bitbucket` image to ensure access to the latest updates and new tags. ## Overview Bitbucket Server is an on-premises source code management solution for Git that's secure, fast, and enterprise grade. Create and manage repositories, set up fine-grained permissions, and collaborate on code - all with the flexibility of your servers. Learn more about Bitbucket Server: This Docker container makes it easy to get an instance of Bitbucket up and running. ???+ note "Embedded OpenSearch" Only Bitbucket versions < 10 include an embedded search server. For backwards-compatibility, by default the image will start both Bitbucket and an embedded OpenSearch. However, this is not a recommended configuration, especially in a clustered environment, and has known issues with shutdown. Instead, we recommend running a separate OpenSearch instance (possibly in another Docker container); see below for instructions on connecting to an external OpenSearch cluster. _* If running this image in a production environment, we strongly recommend you run this image using a specific version tag instead of latest. This is because the image referenced by the latest tag changes often and we cannot guarantee that it will be backwards compatible. *_ **Use docker version >= 20.10.10** ## Quick Start For the `BITBUCKET_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. Additionally, if running Bitbucket in Data Center mode it is required that a shared filesystem is mounted. Volume permission is managed by entry scripts. To get started you can use a data volume, or named volumes. In this example we'll use named volumes. ```shell docker volume create --name bitbucketVolume docker run -v bitbucketVolume:/var/atlassian/application-data/bitbucket --name="bitbucket" -d -p 7990:7990 -p 7999:7999 atlassian/bitbucket ``` Note that this command can substitute folder paths with named volumes. Start Atlassian Bitbucket Server: ```shell docker run -v /data/bitbucket:/var/atlassian/application-data/bitbucket --name="bitbucket" -d -p 7990:7990 -p 7999:7999 atlassian/bitbucket ``` !!! success "Bitbucket is now available on ." Please ensure your container has the necessary resources allocated to it. We recommend 2GiB of memory allocated to accommodate both the application server and the git processes. See [Supported Platforms](https://confluence.atlassian.com/display/BitbucketServer/Supported+platforms) for further information. ???+ tip "If you are using `docker-machine` on Mac OS X, please use `open http://$(docker-machine ip default):7990` instead." ## Common settings ### Verbose container entrypoint logging During the startup process of the container, various operations and checks are performed to ensure that the application is configured correctly and ready to run. To help in troubleshooting and to provide transparency into this process, you can enable verbose logging. The `VERBOSE_LOGS` environment variable enables detailed debug messages to the container's log, offering insights into the actions performed by the entrypoint script. * `VERBOSE_LOGS` (default: false) Set to `true` to enable detailed debug messages during the container initialization. ### Reverse Proxy Settings If Bitbucket is run behind a reverse proxy server as [described here](https://confluence.atlassian.com/bitbucketserver/proxying-and-securing-bitbucket-server-776640099.html), then you need to specify extra options to make Bitbucket aware of the setup. They can be controlled via the below environment variables. * `SERVER_PROXY_NAME` (default: NONE) The reverse proxy's fully qualified hostname. * `SERVER_PROXY_PORT` (default: NONE) The reverse proxy's port number via which bitbucket is accessed. * `SERVER_SCHEME` (default: http) The protocol via which bitbucket is accessed. In certain cloud environments (specifically Kubernetes, Heroku and Cloud Foundry), this setting will be superseded by the value of the `X-Forwarded-Proto` request header if sent by a ingress or load balancer. See `SERVER_FORWARD_HEADERS_STRATEGY` below to alter this behaviour. * `SERVER_SECURE` (default: false) Set 'true' if SERVER\_SCHEME is 'https'. * `SERVER_FORWARD_HEADERS_STRATEGY` (default: NATIVE in the specified cloud environments, NONE otherwise) 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` 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 origin of a request, which means the system will return to the default expected state. ### JVM Configuration (Bitbucket Server 5.0 + only) If you need to override Bitbucket Server's default memory configuration or pass additional JVM arguments, use the environment variables below * `JVM_MINIMUM_MEMORY` (default: 512m) The minimum heap size of the JVM * `JVM_MAXIMUM_MEMORY` (default: 1024m) The maximum heap size of the JVM * `JVM_SUPPORT_RECOMMENDED_ARGS` (default: NONE) Additional JVM arguments for Bitbucket Server, such as a custom Java Trust Store ### Application Mode Settings (Bitbucket Server 5.0 + only) This docker image can be run as a [Smart Mirror](https://confluence.atlassian.com/bitbucketserver/smart-mirroring-776640046.html) or as part of a [Data Center](https://confluence.atlassian.com/enterprise/bitbucket-data-center-668468332.html) cluster. You can specify the following properties to start Bitbucket as a mirror or as a Data Center node: * `SEARCH_ENABLED` (default: true) Note: This property is not applicable for Bitbucket 10.0.0 onwards, as embedded search was removed in Bitbucket 10.
Set 'false' to prevent OpenSearch (previously Elasticsearch) from starting in the container. This should be used if OpenSearch is running remotely, e.g. for if Bitbucket is running in a Data Center cluster. You may also use `ELASTICSEARCH_ENABLED` to set this property, however this is deprecated in favor of `SEARCH_ENABLED`. * `APPLICATION_MODE` (default: default) The mode Bitbucket will run in. This can be set to 'mirror' to start Bitbucket as a Smart Mirror. This will also disable OpenSearch even if `SEARCH_ENABLED` has not been set to 'false'. ### Database Configuration To configure the database automatically on first run, you can provide the following settings: * `JDBC_DRIVER` * `JDBC_URL` * `JDBC_USER` * `JDBC_PASSWORD` Note: Due to licensing restrictions Bitbucket does not ship with a MySQL or Oracle JDBC drivers. To use these databases you will need to copy a suitable driver into the container and restart it. For example, to copy the MySQL driver into a container named "bitbucket", you would do the following: ```shell docker cp mysql-connector-java.x.y.z.jar bitbucket:/var/atlassian/application-data/bitbucket/lib docker restart bitbucket ``` For more information see [Connecting Bitbucket Server to an external database](https://confluence.atlassian.com/bitbucketserver/connecting-bitbucket-server-to-an-external-database-776640378.html). #### JDBC password encryption Starting 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: ```shell docker run \ -e JDBC_DRIVER=org.postgresql.Driver \ -e JDBC_USER=atlbitbucket \ -e JDBC_PASSWORD="{\"region\":\"us-east-1\",\"secretId\":\"mysecret\",\"secretPointer\":\"/password\"}" \ -e JDBC_PASSWORD_DECRYPTER_CLASSNAME="com.atlassian.secrets.store.aws.AwsSecretsManagerStore" \ -e JDBC_URL=jdbc:postgresql://my.database.host:5432/bitbucket \ -v /data/bitbucket-shared:/var/atlassian/application-data/bitbucket/shared \ --name="bitbucket" \ -d -p 7990:7990 -p 7999:7999 \ atlassian/bitbucket ``` Of 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. ## Other settings As well as the above settings, all settings that are available in the [bitbucket.properties file](https://confluence.atlassian.com/bitbucketserver/bitbucket-server-config-properties-776640155.html) can also be provided via Docker environment variables. For a full explanation of converting Bitbucket properties into environment variables see [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). To translate a property name into an environment variable: * dot `.` becomes underscore `_` * dash `-` becomes underscore `_` * Example: `this.new-property` becomes `THIS_NEW_PROPERTY` For example, a full command-line for a Bitbucket node with a PostgreSQL database, and an external OpenSearch instance might look like: ```shell docker network create --driver bridge --subnet=172.18.0.0/16 myBitbucketNetwork docker run --network=myBitbucketNetwork --ip=172.18.1.1 \ -e SEARCH_ENABLED=false \ -e JDBC_DRIVER=org.postgresql.Driver \ -e JDBC_USER=atlbitbucket \ -e JDBC_PASSWORD=MYPASSWORDSECRET \ -e JDBC_URL=jdbc:postgresql://my.database.host:5432/bitbucket \ -e PLUGIN_SEARCH_CONFIG_BASEURL=http://my.opensearch.host \ -v /data/bitbucket-shared:/var/atlassian/application-data/bitbucket/shared \ --name="bitbucket" \ -d -p 7990:7990 -p 7999:7999 \ atlassian/bitbucket ``` ### Cluster settings If running a clustered Bitbucket DC instance, the cluster settings are specified with `HAZELCAST_*` environment variables. The main ones to be aware of are: * `HAZELCAST_PORT` (`hazelcast.port`) * `HAZELCAST_GROUP_NAME` (`hazelcast.group.name`) * `HAZELCAST_GROUP_PASSWORD` (`hazelcast.group.password`) Each clustering type (e.g. AWS/Azure/Multicast/TCP) has its own settings. For more information on clustering Bitbucket, and other properties see [Clustering with Bitbucket Data Center](https://confluence.atlassian.com/bitbucketserver/clustering-with-bitbucket-data-center-776640164.html) and [Clustering with Bitbucket Data Center](https://confluence.atlassian.com/bitbucketserver/bitbucket-server-config-properties-776640155.html). ???+ note "Out-of-scope network configuration" The underlying network should be configured to support the clustering type you are using. How to do this depends on the container management technology, and is beyond the scope of this documentation. ### JMX Monitoring JMX monitoring can be enabled with `JMX_ENABLED=true`. Information on additional settings and available metrics is available in the [Bitbucket JMX documentation](https://confluence.atlassian.com/bitbucketserver/enabling-jmx-counters-for-performance-monitoring-776640189.html). ## Container Configuration * `SET_PERMISSIONS` (default: true) Define whether to set home directory permissions on startup. Set to `false` to disable this behaviour. ## Shared directory and user IDs By default the Bitbucket application runs as the user `bitbucket`, with a UID and GID of 2003. Consequently this UID must have write access to the shared filesystem. If for some reason a different UID must be used, there are a number of options available: * The Docker image can be rebuilt with a different UID. * Under Linux, the UID can be remapped using [user namespace remapping](https://docs.docker.com/engine/security/userns-remap/). ## Upgrade To upgrade to a more recent version of Bitbucket Server you can simply stop the `bitbucket` container and start a new one based on a more recent image: ```shell docker stop bitbucket docker rm bitbucket docker pull atlassian/bitbucket: docker run ... (See above) ``` As your data is stored in the data volume directory on the host it will still be available after the upgrade. !!! note "Please make sure that you **don't** accidentally remove the `bitbucket` container and its volumes using the `-v` option." ## Backup For evaluations you can use the built-in database that will store its files in the Bitbucket Server home directory. In that case it is sufficient to create a backup archive of the directory on the host that is used as a volume (`/data/bitbucket` in the example above). The [Bitbucket Server Backup Client](https://confluence.atlassian.com/display/BitbucketServer/Data+recovery+and+backups) is currently not supported in the Docker setup. You can however use the [Bitbucket Server DIY Backup](https://confluence.atlassian.com/display/BitbucketServer/Using+Bitbucket+Server+DIY+Backup) approach in case you decided to use an external database. Read more about data recovery and backups: [https://confluence.atlassian.com/display/BitbucketServer/Data+recovery+and+backups](https://confluence.atlassian.com/display/BitbucketServer/Data+recovery+and+backups) ## Shutdown Bitbucket allows a configurable grace period for active operations to finish before termination; by default this is 30s. If sending a `docker stop` this should be taken into account with the `--time` flag. Alternatively, the script `/shutdown-wait.sh` is provided, which will initiate a clean shutdown and wait for the process to complete. This is the recommended method for shutdown in environments which provide for orderly shutdown, e.g. Kubernetes via the `preStop` hook. ## Versioning The `latest` tag matches the most recent version of this repository. Thus using `atlassian/bitbucket:latest` or `atlassian/bitbucket` will ensure you are running the most up to date version of this image. Alternatively, you can use a specific minor version of Bitbucket Server by using a version number tag: `atlassian/bitbucket:6`. This will install the latest `6.x.x` version that is available. ## Supported JDK versions and base images All the Atlassian Docker images are now JDK11 and JDK17 (starting from 8.8 version), and generated from the [official Eclipse Temurin OpenJDK Docker images](https://hub.docker.com/_/eclipse-temurin). Starting from 8.18 [UBI based](https://catalog.redhat.com/software/containers/ubi9/openjdk-17/61ee7c26ed74b2ffb22b07f6?architecture=amd64) tags are published as well. UBI tags are available in 2 formats: `-ubi9` and `-ubi9-jdk17`. The Docker images follow the [Atlassian Support end-of-life policy](https://confluence.atlassian.com/support/atlassian-support-end-of-life-policy-201851003.html); images for unsupported versions of the products remain available but will no longer receive updates or fixes. Historically, we have also generated other versions of the images, including JDK8, Alpine, and 'slim' versions of the JDK. These legacy images still exist in Docker Hub, however they should be considered deprecated, and do not receive updates or fixes. If for some reason you need a different version, see "Building your own image" ## Migration to UBI If 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`. Also, 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). ## Building your own image * Clone the Atlassian repository at https://bitbucket.org/atlassian-docker/docker-atlassian-bitbucket-server/ * Modify or replace the [Jinja](https://jinja.palletsprojects.com/) templates under `config`; _NOTE_: The files must have the `.j2` extensions. However, you don't have to use template variables if you don't wish. * Build the new image with e.g: `docker build --tag my-bitbucket-image --build-arg BITBUCKET_VERSION=8.x.x .` * Optionally push to a registry, and deploy. ## Supported architectures Currently, Bitbucket container images are built for the `linux/amd64` and `linux/arm64` target platforms. The Dockerfiles and support tooling have now had all architecture-specific components removed, so if necessary it is possible to build images for any platform supported by OCI-compliant container runtimes. ## Building on the target architecture The simplest method of getting a platform image is to build it on a target machine; see "Building your own image" above. Note: This method is known to work on Mac M1 and AWS ARM64 machines, but has not been extensively tested. ## Troubleshooting These images include built-in scripts to assist in performing common JVM diagnostic tasks. ### Thread dumps `/opt/atlassian/support/thread-dumps.sh` can be run via `docker exec` to easily trigger the collection of thread dumps from the containerized application. For example: ```shell docker exec my_container /opt/atlassian/support/thread-dumps.sh ``` By default, this script will collect 10 thread dumps at 5 second intervals. This can be overridden by passing a custom value for the count and interval, by using `-c` / `--count` and `-i` / `--interval` respectively. For example, to collect 20 thread dumps at 3 second intervals: ```shell docker exec my_container /opt/atlassian/support/thread-dumps.sh --count 20 --interval 3 ``` Thread dumps will be written to `$APP_HOME/thread_dumps/`. ???+ note "Disable capturing output from top run" By default this script will also capture output from top run in 'Thread-mode'. This can be disabled by passing `-n` / `--no-top` ### Heap dump `/opt/atlassian/support/heap-dump.sh` can be run via `docker exec` to easily trigger the collection of a heap dump from the containerized application. For example: ```shell docker exec my_container /opt/atlassian/support/heap-dump.sh ``` A heap dump will be written to `$APP_HOME/heap.bin`. If a file already exists at this location, use `-f` / `--force` to overwrite the existing heap dump file. ### Manual diagnostics The `jcmd` utility is also included in these images and can be used by starting a `bash` shell in the running container: ```shell docker exec -it my_container /bin/bash ``` ## Support For product support, go to [support.atlassian.com](https://support.atlassian.com/) You can also visit the [Atlassian Data Center](https://community.atlassian.com/t5/Atlassian-Data-Center-on/gh-p/DC_Kubernetes) forum for discussion on running Atlassian Data Center products in containers. ## Changelog For a detailed list of changes to the Docker image configuration see [the Git commit history](https://bitbucket.org/atlassian-docker/docker-atlassian-bitbucket-server/commits/). ## License Copyright © 2019 Atlassian Corporation Pty Ltd. Licensed under the Apache License, Version 2.0. ================================================ FILE: docs/docs/containers/CONFLUENCE.md ================================================ # ![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 !!! warning "Server image deprecation" This Docker image has been published as both `atlassian/confluence` and `atlassian/confluence-server` up until February 15, 2024. Both names refer to the same image. However, post-February 15, 2024, the `atlassian/confluence-server` version ceased receiving updates, including both existing and new tags. If you have been using `atlassian/confluence-server`, switch to the `atlassian/confluence` image to ensure access to the latest updates and new tags. ## Overview Confluence Server is where you create, organise and discuss work with your team. Capture the knowledge that's too often lost in email inboxes and shared network drives in Confluence - where it's easy to find, use, and update. Give every team, project, or department its own space to create the things they need, whether it's meeting notes, product requirements, file lists, or project plans, you can get more done in Confluence. This Docker container makes it easy to get an instance of Confluence up and running. Learn more about Confluence Server: You can find the repository with the Dockerfile at DockerHub repository: **Use docker version >= 20.10.10** ## Quick Start For the directory in the environmental variable `CONFLUENCE_HOME` that is used to store Confluence data (amongst other things) we recommend mounting a host directory as a [data volume][1]: Additionally, if running Confluence in Data Center mode it is required that a shared filesystem is mounted. The mountpoint (inside the container) can be configured with `CONFLUENCE_SHARED_HOME`. Start Atlassian Confluence Server: ```shell docker run -v /data/your-confluence-home:/var/atlassian/application-data/confluence --name="confluence" -d -p 8090:8090 -p 8091:8091 atlassian/confluence ``` !!! success "Confluence is now available on ." Please ensure your container has the necessary resources allocated to it. We recommend 2GiB of memory allocated to accommodate the application server. See [Supported Platforms][3] for further information. ???+ tip "If you are using `docker-machine` on Mac OS X, please use `open http://$(docker-machine ip default):8090` instead." ## Configuring Confluence This Docker image is intended to be configured from its environment; the provided information is used to generate the application configuration files from templates. This allows containers to be repeatably created and destroyed on-the-fly, as required in advanced cluster configurations. Most aspects of the deployment can be configured in this manner; the necessary environment variables are documented below. However, if your particular deployment scenario is not covered by these settings, it is possible to override the provided templates with your own; see the section [Advanced Configuration](#advanced-configuration) below. ### Verbose container entrypoint logging During the startup process of the container, various operations and checks are performed to ensure that the application is configured correctly and ready to run. To help in troubleshooting and to provide transparency into this process, you can enable verbose logging. The `VERBOSE_LOGS` environment variable enables detailed debug messages to the container's log, offering insights into the actions performed by the entrypoint script. * `VERBOSE_LOGS` (default: false) Set to `true` to enable detailed debug messages during the container initialization. ### Memory / Heap Size If you need to override Confluence Server's default memory allocation, you can control the minimum heap (Xms) and maximum heap (Xmx) via the below environment variables. * `JVM_MINIMUM_MEMORY` (default: 1024m) The minimum heap size of the JVM * `JVM_MAXIMUM_MEMORY` (default: 1024m) The maximum heap size of the JVM * `JVM_RESERVED_CODE_CACHE_SIZE` (default: 256m) The reserved code cache size of the JVM ### Tomcat and Reverse Proxy Settings If Confluence is run behind a reverse proxy server (e.g. a load-balancer or nginx server), then you need to specify extra options to make Confluence aware of the setup. They can be controlled via the below environment variables. * `ATL_PROXY_NAME` (default: NONE) The reverse proxy's fully qualified hostname. `CATALINA_CONNECTOR_PROXYNAME` is also supported for backwards compatability. * `ATL_PROXY_PORT` (default: NONE) The reverse proxy's port number via which Confluence is accessed. `CATALINA_CONNECTOR_PROXYPORT` is also supported for backwards compatability. * `ATL_TOMCAT_PORT` (default: 8090) The port for Tomcat/Confluence to listen on. Depending on your container deployment method this port may need to be [exposed and published][docker-expose]. * `ATL_TOMCAT_SCHEME` (default: http) The protocol via which Confluence is accessed. `CATALINA_CONNECTOR_SCHEME` is also supported for backwards compatability. * `ATL_TOMCAT_SECURE` (default: false) Set 'true' if `ATL_TOMCAT_SCHEME` is 'https'. `CATALINA_CONNECTOR_SECURE` is also supported for backwards compatability. * `ATL_TOMCAT_CONTEXTPATH` (default: NONE) The context path the application is served over. `CATALINA_CONTEXT_PATH` is also supported for backwards compatability. * `ATL_TOMCAT_ACCESS_LOG` (default: false [version < 7.11.0] and true [version >=7.11.0]) Whether to enable Tomcat access logging; set to `true` to enable. *NOTE*: These logs are written to the Container internal volume by default (under `/opt/atlassian/confluence/logs/`); these are rotated but not removed, and will grow indefinitely. If you enable this functionality it is recommended that you map the directory to a volume and perform log ingestion/cleanup with external tools. * `ATL_TOMCAT_REQUESTATTRIBUTESENABLED` Checks for the existence of request attributes (typically set by the RemoteIpValve and similar) that should be used to override the values returned by the request for remote address, remote host, server port and protocol. This property is usually combined with `ATL_TOMCAT_TRUSTEDPROXIES` and `ATL_TOMCAT_INTERNALPROXIES` to show IP address of the remote host instead of the load balancer's. If not declared, the default value of `false` will be used. * `ATL_TOMCAT_TRUSTEDPROXIES` A list of IP addresses separated by a pipe character e.g. `10.0.9.6|10.0.9.32`. Trusted proxies that appear in the `remoteIpHeader` will be trusted and *will appear* in the `proxiesHeader` value. By adding a list of Trusted Proxies, Confluence will remove the load balancers' IP addresses from Confluence's view of the incoming connection. This could be desired in a clustered load balancer architecture where the load balancer address changes depending on which node proxies the connection. If not specified, no trusted proxies will be trusted. * `ATL_TOMCAT_INTERNALPROXIES` A list of IP addresses separated by a pipe character e.g. `10.0.9.6|10.0.9.32`. Trusted proxies that appear in the `remoteIpHeader` will be trusted and *will not appear* in the `proxiesHeader` value. By adding a list of Internal Proxies, Confluence will remove the load balancers' IP addresses from Confluence's view of the incoming connection. This could be desired in a clustered load balancer architecture where the load balancer address changes depending on which node proxies the connection. If not specified, no internal proxies will be trusted. * `ATL_TOMCAT_ADDITIONAL_CONNECTOR_PORT` - If unset, no additional connector is defined in server.xml. No default. * `ATL_TOMCAT_ADDITIONAL_CONNECTOR_CONNECTION_TIMEOUT` (default: 20000) * `ATL_TOMCAT_ADDITIONAL_CONNECTOR_MAX_THREADS` (default: 50) * `ATL_TOMCAT_ADDITIONAL_CONNECTOR_MIN_SPARE_THREADS` (default: 10) * `ATL_TOMCAT_ADDITIONAL_CONNECTOR_ENABLE_LOOKUPS` (default: false) * `ATL_TOMCAT_ADDITIONAL_CONNECTOR_ACCEPT_COUNT` (default: 10) * `ATL_TOMCAT_ADDITIONAL_CONNECTOR_URI_ENCODING` (default: UTF-8) * `ATL_TOMCAT_ADDITIONAL_CONNECTOR_SECURE` (no default, if undefined secure is not set in the connector) The following Tomcat/Catalina options are also supported. For more information, see . * `ATL_TOMCAT_MGMT_PORT` (default: 8000) * `ATL_TOMCAT_MAXTHREADS` (default: 48) * `ATL_TOMCAT_MINSPARETHREADS` (default: 10) * `ATL_TOMCAT_CONNECTIONTIMEOUT` (default: 20000) * `ATL_TOMCAT_ENABLELOOKUPS` (default: false) * `ATL_TOMCAT_PROTOCOL` (default: org.apache.coyote.http11.Http11NioProtocol) * `ATL_TOMCAT_REDIRECTPORT` (default: 8443) * `ATL_TOMCAT_ACCEPTCOUNT` (default: 10) * `ATL_TOMCAT_DEBUG` (default: 0) * `ATL_TOMCAT_URIENCODING` (default: UTF-8) * `ATL_TOMCAT_MAXHTTPHEADERSIZE` (default: 8192) * `ATL_TOMCAT_STUCKTHREADDETECTIONVALVE_THRESHOLD` (default: 60) ### Access Log Settings You 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. * `ATL_TOMCAT_ACCESS_LOGS_MAXDAYS` (default: -1) * `ATL_TOMCAT_ACCESS_LOG_PATTERN` (default: `%h %{X-AUSERNAME}o %t "%r" %s %b %D %U %I "%{User-Agent}i"`) ### JVM configuration If you need to pass additional JVM arguments to Confluence such as specifying a custom trust store, you can add them via the below environment variable * `JVM_SUPPORT_RECOMMENDED_ARGS` Additional JVM arguments for Confluence. ??? example `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` For additional settings that can be supplied, see: [Recognized System Properties](https://confluence.atlassian.com/doc/recognized-system-properties-190430.html) ### Confluence-specific settings * `ATL_AUTOLOGIN_COOKIE_AGE` (default: 1209600; two weeks, in seconds) The maximum time a user can remain logged-in with 'Remember Me'. * `CONFLUENCE_HOME` The confluence home directory. This may be on an mounted volume; if so it should be writable by the user `confluence`. See note below about UID mappings. * `ATL_LUCENE_INDEX_DIR` The directory where [Lucene](https://lucene.apache.org/) search indexes should be stored. Defaults to `index` under the Confluence home directory. * `ATL_LICENSE_KEY` (from Confluence 7.9 onwards) The Confluence license string. Providing this will remove the need to supply it through the web startup screen. * **use with caution** `CONFLUENCE_LOG_STDOUT` `[true, false]` (from Confluence 7.9 onwards) Prior to Confluence version 7.9.0, the log files are always stored in the `logs` folder in Confluence home. From version 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 via `docker logs `. In this setup we recommend using some log aggregation tooling (e.g. AWS Cloudwatch or ELK stack). **Beware, if enabled, the support ZIP produced by the Troubleshooting and Support plugin doesn't contain the application logs.** * `ATL_SEARCH_PLATFORM` 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 * `ATL_OPENSEARCH_HTTP_URL` HTTP(S) URL of the OpenSearch cluster, or multiple URLs separated by commas. * `ATL_OPENSEARCH_USERNAME` Username for the OpenSearch cluster. * `ATL_OPENSEARCH_PASSWORD` Password for the OpenSearch cluster. * `ATL_CONFLUENCE_SESSION_TIMEOUT` The default Tomcat session timeout (in minutes) for all newly created sessions which is set in web.xml. Defaults to 30. * `ATL_CONFLUENCE_CFG_ADDITIONAL_PROPERTIES` 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`. ### Database configuration It is optionally possible to configure the database from the environment, avoiding the need to do so through the web startup screen. The following variables are all must all be supplied if using this feature: * `ATL_JDBC_URL` The database URL; this is database-specific. It is allowed to use `&` in the URL which will be automatically converted to `&`. * `ATL_JDBC_USER` The database user to connect as. * `ATL_JDBC_PASSWORD` The password for the database user. * `ATL_DB_TYPE` The type of database; valid supported values are: * `mssql` * `mysql` * `oracle12c` (Confluence 7.3.0 or earlier only) * `oracle` (Confluence 7.3.1 or later only. Compatible with Oracle 12c and Oracle 19c) * `postgresql` ???+ note "MySQL or Oracle JDBC drivers" Due to licensing restrictions Confluence does not ship with a MySQL or Oracle JDBC drivers. To use these databases you will need to copy a suitable driver into the container and restart it. For example, to copy the MySQL driver into a container named "confluence", you would do the following: `docker cp mysql-connector-java.x.y.z.jar confluence:/opt/atlassian/confluence/confluence/WEB-INF/lib` `docker restart confluence` For more information see the [Database JDBC Drivers](https://confluence.atlassian.com/doc/database-jdbc-drivers-171742.html) page. #### Optional database settings * `ATL_JDBC_SECRET_CLASS` [Encryption class](https://confluence.atlassian.com/doc/encrypt-database-password-1115674739.html) for the database password. Depending on the secret class, the value of `ATL_JDBC_PASSWORD` will differ. Defaults to plaintext. !!! warning "JDBC encryption can only be used with Confluence instances that have already been set up." Starting from 8.6 [AWS SecretsManager](https://confluence.atlassian.com/doc/configuring-confluence-with-aws-secrets-manager-1299911239.html) is supported. For 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. For clustered Confluence, set this property while making sure environment variables in [cluster configuration](#cluster-configuration) are kept intact as well. Example: ```shell docker run -v /data/your-confluence-home:/var/atlassian/application-data/confluence \ --name="confluence" -d -p 8090:8090 -p 8091:8091 \ -e ATL_JDBC_SECRET_CLASS='com.atlassian.secrets.store.aws.AwsSecretsManagerStore' \ -e ATL_JDBC_PASSWORD='{"region": "us-east-1", "secretId": "mysecret", "secretPointer": "/password"}' \ -e ATL_CLUSTER_RELATED_VARIABLES='variable-value' \ atlassian/confluence ``` The following variables are for the database connection pool, and are optional. * `ATL_DB_POOLMINSIZE` (default: 20) * `ATL_DB_POOLMAXSIZE` (default: 100) * `ATL_DB_TIMEOUT` (default: 30) * `ATL_DB_IDLETESTPERIOD` (default: 100) * `ATL_DB_MAXSTATEMENTS` (default: 0) * `ATL_DB_VALIDATE` (default: false) * `ATL_DB_ACQUIREINCREMENT` (default: 1) * `ATL_DB_VALIDATIONQUERY` (default: "select 1") * `ATL_DB_PROVIDER_CLASS` (default: `com.atlassian.confluence.impl.hibernate.DelegatingHikariConnectionProvider`) * `ATL_DB_CONNECTION_AUTOCOMMIT` (default false) * `ATL_DB_CONNECTION_ISOLATION` (default 2) * `ATL_DB_DATASOURCE_HIKARI_REGISTER_MBEANS` (default true) ### Data Center configuration This docker image can be run as part of a [Data Center][4] cluster. You can specify the following properties to start Confluence as a Data Center node, instead of manually configuring a cluster. See [Installing Confluence Data Center][5] for more information. #### Cluster configuration Confluence Data Center allows clustering via various methods. For more information on the setting for each type see [this page][6]. **NOTE:** The underlying network should be set-up to support the Confluence clustering type you are using. How to do this depends on the container management technology, and is beyond the scope of this documentation. ##### Common cluster settings * `ATL_CLUSTER_TYPE` The cluster type. Setting this effectively enables clustering. Valid values are `aws`, `multicast`, and `tcp_ip`. * `ATL_CLUSTER_NAME` The cluster name; this should be common across all nodes. * `ATL_PRODUCT_HOME_SHARED` The location of the shared home directory for all Confluence nodes. **Note**: This must be real shared filesystem that is mounted inside the container. Additionally, see the note about UIDs. * `ATL_CLUSTER_TTL` The time-to-live for cluster packets. Primarily of use in multicast clusters. * `ATL_CLUSTER_INTERFACE` The network interface Confluence will use to communicate between nodes. Auto-detected by default. [Override interface](https://confluence.atlassian.com/doc/data-center-troubleshooting-203618.html#DataCenterTroubleshooting-Changemulticastinterface) if Confluence has selected the wrong one. ##### AWS cluster settings The following should be populated from the AWS environment. * `ATL_HAZELCAST_NETWORK_AWS_IAM_ROLE` * `ATL_HAZELCAST_NETWORK_AWS_IAM_REGION` * `ATL_HAZELCAST_NETWORK_AWS_HOST_HEADER` * `ATL_HAZELCAST_NETWORK_AWS_SECURITY_GROUP` * `ATL_HAZELCAST_NETWORK_AWS_TAG_KEY` * `ATL_HAZELCAST_NETWORK_AWS_TAG_VALUE` ##### TCP cluster settings * `ATL_CLUSTER_PEERS` A comma-separated list of peer IPs. ##### Multicast cluster settings * `ATL_CLUSTER_ADDRESS` The multicast address the cluster will communicate on. ### Container Configuration * `ATL_FORCE_CFG_UPDATE` (default: false) The Docker [entrypoint][13] generates application configuration on first start; not all of these files are regenerated on subsequent starts. This is deliberate, to avoid race conditions or overwriting manual changes during restarts and upgrades. However in deployments where configuration is purely specified through the environment (e.g. Kubernetes) this behaviour may be undesirable; this flag forces an update of all generated files. In Confluence the affected files are: `confluence.cfg.xml` See [the entrypoint code][13] for the details of how configuration files are generated. * `SET_PERMISSIONS` (default: true) Define whether to set home directory permissions on startup. Set to `false` to disable this behaviour. * `ATL_UNSET_SENSITIVE_ENV_VARS` (default: true) Define whether to unset environment variables containing keywords 'PASS', 'SECRET' or 'TOKEN'. The unset function is executed in the entrypoint. Set to `false` if you want to allow passing sensitive environment variables to Confluence container. ???+ warning "Value exposure on host OS" When using this property, the values to sensitive environment variables will be available in clear text on the host OS. As such, this data may be exposed to users or processes running on the host OS. * `ATL_ALLOWLIST_SENSITIVE_ENV_VARS` 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. ???+ warning "Value exposure on host OS" When using this property, the values to sensitive environment variables will be available in clear text on the host OS. As such, this data may be exposed to users or processes running on the host OS. ### Advanced Configuration As mentioned at the top of this section, the settings from the environment are used to populate the application configuration on the container startup. However, in some cases you may wish to customise the settings in ways that are not supported by the environment variables above. In this case, it is possible to modify the base templates to add your own configuration. There are three main ways of doing this; modify our repository to your own image, build a new image from the existing one, or provide new templates at startup. We will briefly outline these methods here, but in practice how you do this will depend on your needs. ##### Building your own image * Clone the Atlassian repository at * Modify or replace the [Jinja](https://jinja.palletsprojects.com/) templates under `config`; _NOTE_: The files must have the `.j2` extensions. However you don't have to use template variables if you don't wish. * Build the new image with e.g: `docker build --tag my-confluence-image --build-arg CONFLUENCE_VERSION=6.x.x .` * Optionally push to a registry, and deploy. ##### Build a new image from the existing one * Create a new `Dockerfile`, which starts with the line e.g: `FROM atlassian/confluence:latest`. * Use a `COPY` line to overwrite the provided templates. * Build, push and deploy the new image as above. ##### Overwrite the templates at runtime There are two main ways of doing this: * If your container is going to be long-lived, you can create it, modify the installed templates under `/opt/atlassian/etc/`, and then run it. * Alternatively, you can create a volume containing your alternative templates, and mount it over the provided templates at runtime with `--volume my-config:/opt/atlassian/etc/`. ## Shared directory and user IDs By default the Confuence application runs as the user `confluence`, with a UID and GID of 2002. Consequently this UID must have write access to the shared filesystem. If for some reason a different UID must be used, there are a number of options available: * The Docker image can be rebuilt with a different UID. * Under Linux, the UID can be remapped using [user namespace remapping][7]. To preserve strict permissions for certain configuration files, this container starts as `root` to perform bootstrapping before running Confluence under a non-privileged user account. If you wish to start the container as a non-root user, please note that Tomcat configuration, and the bootstrapping of seraph-config.xml (SSO) & confluence-init.properties (overriding `$CONFLUENCE_HOME`) will be skipped and a warning will be logged. You may still apply custom configuration in this situation by mounting a custom file directly, e.g. by mounting your own server.xml file directly to `/opt/atlassian/confluence/conf/server.xml` Database and Clustering bootstrapping will work as expected when starting this container as a non-root user. ## Upgrade To upgrade to a more recent version of Confluence Server you can simply stop the `Confluence` container and start a new one based on a more recent image: ```shell docker stop confluence docker rm confluence docker run ... (see above) ``` As your data is stored in the data volume directory on the host, it will still be available after the upgrade. !!! note "Please make sure that you **don't** accidentally remove the `confluence` container and its volumes using the `-v` option." ## Backup For evaluating Confluence you can use the built-in database that will store its files in the Confluence Server home directory. In that case it is sufficient to create a backup archive of the directory on the host that is used as a volume (`/data/your-confluence-home` in the example above). Confluence's [automatic backup][8] is currently supported in the Docker setup. You can also use the [Production Backup Strategy][9] approach if you're using an external database. Read more about data recovery and backups: [Site Backup and Restore][10] ## Shutdown Confluence allows a grace period of 20s for active operations to finish before termination. If sending a `docker stop` this should be taken into account with the `--time` flag. Alternatively, the script `/shutdown-wait.sh` is provided, which will initiate a clean shutdown and wait for the process to complete. This is the recommended method for shutdown in environments which provide for orderly shutdown, e.g. Kubernetes via the `preStop` hook. ## Versioning The `latest` tag matches the most recent official release of Atlassian Confluence Server. So `atlassian/confluence:latest` will use the newest stable version of Confluence Server available. Alternatively, you can use a specific minor version of Confluence Server by using a version number tag: `atlassian/confluence:7.13`. This will install the latest `7.13.x` version that is available. We also publish docker images for our [EAP releases](https://www.atlassian.com/software/confluence/download-eap) (not supported for use in production). The tag for EAP releases is the EAP version. For example to get the `7.8.0-beta1` EAP release, use `atlassian/confluence:7.8.0-beta1`. For example, `atlassian/confluence:7.13-ubuntu-jdk11` will install the latest 7.13.x version with Eclipse Temurin OpenJDK 11. ## Supported JDK versions and base images Atlassian Docker images are generated from the [official Eclipse Temurin OpenJDK Docker images](https://hub.docker.com/_/eclipse-temurin). Starting from 8.5.6 [UBI based](https://catalog.redhat.com/software/containers/ubi9/openjdk-17/61ee7c26ed74b2ffb22b07f6?architecture=amd64) tags are published as well. Tags are available in 2 formats: `-ubi9` and `-ubi9-jdk17`. The build pipeline pushes both JDK11 and JDK17 tags for Confluence versions ranging from 7.19 to 8.9. Starting from 9.0 only JDK17 tags are published. UBI based tags are JDK17 only. The Docker images follow the [Atlassian Support end-of-life policy](https://confluence.atlassian.com/support/atlassian-support-end-of-life-policy-201851003.html); images for unsupported versions of the products remain available but will no longer receive updates or fixes. Historically, we have also generated other versions of the images, including JDK8, Alpine, and 'slim' versions of the JDK. These legacy images still exist in Docker Hub, however they should be considered deprecated, and do not receive updates or fixes. If for some reason you need a different version, see "Building your own image" above. ## Migration to UBI If 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`. Also, 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). ## Supported architectures Currently, Confluence container images are built for the `linux/amd64` and `linux/arm64` target platforms. The Dockerfiles and support tooling have now had all architecture-specific components removed, so if necessary it is possible to build images for any platform supported by OCI-compliant container runtimes. ### Building on the target architecture Note: This method is known to work on Mac M1 and AWS ARM64 machines, but has not been extensively tested. The simplest method of getting a platform image is to build it on a target machine. The following assumes you have git and Docker installed. You will also need to know which version of Confluence you want to build; substitute `CONFLUENCE_VERSION=x.x.x` with your required version: ```shell git clone --recurse-submodule https://bitbucket.org/atlassian-docker/docker-atlassian-confluence-server.git cd docker-atlassian-confluence-server docker build --tag my-image --build-arg CONFLUENCE_VERSION=x.x.x . ``` This image can be pushed up to your own Docker Hub or private repository. ## Troubleshooting These images include built-in scripts to assist in performing common JVM diagnostic tasks. ### Thread dumps `/opt/atlassian/support/thread-dumps.sh` can be run via `docker exec` to easily trigger the collection of thread dumps from the containerized application. For example: ```shell docker exec my_container /opt/atlassian/support/thread-dumps.sh ``` By default, this script will collect 10 thread dumps at 5 second intervals. This can be overridden by passing a custom value for the count and interval, by using `-c` / `--count` and `-i` / `--interval` respectively. For example, to collect 20 thread dumps at 3 second intervals: ```shell docker exec my_container /opt/atlassian/support/thread-dumps.sh --count 20 --interval 3 ``` Thread dumps will be written to `$APP_HOME/thread_dumps/`. ???+ note "Disable capturing output from top run" By default this script will also capture output from top run in 'Thread-mode'. This can be disabled by passing `-n` / `--no-top` ### Heap dump `/opt/atlassian/support/heap-dump.sh` can be run via `docker exec` to easily trigger the collection of a heap dump from the containerized application. For example: ```shell docker exec my_container /opt/atlassian/support/heap-dump.sh ``` A heap dump will be written to `$APP_HOME/heap.bin`. If a file already exists at this location, use `-f` / `--force` to overwrite the existing heap dump file. ### Manual diagnostics The `jcmd` utility is also included in these images and can be used by starting a `bash` shell in the running container: ```shell docker exec -it my_container /bin/bash ``` ## Support For product support, go to [support.atlassian.com](https://support.atlassian.com/confluence-server/). You can also visit the [Atlassian Data Center](https://community.atlassian.com/t5/Atlassian-Data-Center-on/gh-p/DC_Kubernetes) forum for discussion on running Atlassian Data Center products in containers. ## Contribution See the [contributing guideline][14] if you are contributing from outside Atlassian. ## Changelog For a detailed list of changes to the Docker image configuration see [the Git commit history](https://bitbucket.org/atlassian-docker/docker-atlassian-confluence-server/commits/). ## License Copyright © 2020 Atlassian Corporation Pty Ltd. Licensed under the Apache License, Version 2.0. [1]: https://docs.docker.com/userguide/dockervolumes/#mount-a-host-directory-as-a-data-volume [3]: https://confluence.atlassian.com/display/DOC/Supported+platforms [4]: https://confluence.atlassian.com/doc/confluence-data-center-technical-overview-790795847.html [5]: https://confluence.atlassian.com/doc/installing-confluence-data-center-203603.html [6]: https://confluence.atlassian.com/doc/change-node-discovery-from-multicast-to-tcp-ip-or-aws-792297728.html#ChangeNodeDiscoveryfromMulticasttoTCP/IPorAWS-TochangefromTCP/IPtomulticast [7]: https://docs.docker.com/engine/security/userns-remap/ [8]: https://confluence.atlassian.com/display/DOC/Configuring+Backups [9]: https://confluence.atlassian.com/display/DOC/Production+Backup+Strategy [10]: https://confluence.atlassian.com/display/DOC/Site+Backup+and+Restore [12]: https://confluence.atlassian.com/doc/confluence-6-13-release-notes-959288785.html [13]: https://bitbucket.org/atlassian-docker/docker-atlassian-confluence-server/src/master/entrypoint.py [14]: https://bitbucket.org/atlassian-docker/docker-atlassian-confluence-server/src/master/CONTRIBUTING.md ================================================ FILE: docs/docs/containers/CROWD.md ================================================ # ![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 ## Overview Crowd provides single sign-on and user identity that's easy to use. Learn more about Crowd: [https://www.atlassian.com/software/crowd][1] This Docker container makes it easy to get an instance of Crowd up and running. **Use docker version >= 20.10.10** ## Quick Start For 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. To get started you can use a data volume, or named volumes. In this example we'll use named volumes. ```shell docker volume create --name crowdVolume docker run -v crowdVolume:/var/atlassian/application-data/crowd --name="crowd" -d -p 8095:8095 atlassian/crowd ``` !!! success "Crowd is now available on [http://localhost:8095](http://localhost:8095)." Please ensure your container has the necessary resources allocated to it. See [Supported Platforms][2] for further information. ???+ tip "If you are using `docker-machine` on Mac OS X, please use `open http://$(docker-machine ip default):8095` instead." ## Common settings ### Verbose container entrypoint logging During the startup process of the container, various operations and checks are performed to ensure that the application is configured correctly and ready to run. To help in troubleshooting and to provide transparency into this process, you can enable verbose logging. The `VERBOSE_LOGS` environment variable enables detailed debug messages to the container's log, offering insights into the actions performed by the entrypoint script. * `VERBOSE_LOGS` (default: false) Set to `true` to enable detailed debug messages during the container initialization. ### Memory / Heap Size If 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. * `JVM_MINIMUM_MEMORY` (default: 384m) The minimum heap size of the JVM * `JVM_MAXIMUM_MEMORY` (default: 768m) The maximum heap size of the JVM ### Reverse Proxy Settings If 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. * `ATL_TOMCAT_CONTEXTPATH` (default: /crowd) The context path the application is served over. * `ATL_PROXY_NAME` (default: NONE) The reverse proxy's fully qualified hostname. `CATALINA_CONNECTOR_PROXYNAME` is also supported for backwards compatability. * `ATL_PROXY_PORT` (default: NONE) The reverse proxy's port number via which Crowd is accessed. `CATALINA_CONNECTOR_PROXYPORT` is also supported for backwards compatability. * `ATL_TOMCAT_PORT` (default: 8095) The port for Tomcat/Crowd to listen on. Depending on your container deployment method this port may need to be [exposed and published][docker-expose]. * `ATL_TOMCAT_SCHEME` (default: http) The protocol via which Crowd is accessed. `CATALINA_CONNECTOR_SCHEME` is also supported for backwards compatability. * `ATL_TOMCAT_SECURE` (default: false) Set 'true' if `ATL_TOMCAT_SCHEME` is 'https'. `CATALINA_CONNECTOR_SECURE` is also supported for backwards compatability. The following Tomcat/Catalina options are also supported. For more information, see https://tomcat.apache.org/tomcat-8.5-doc/config/index.html. * `ATL_TOMCAT_MGMT_PORT` (default: 8000) * `ATL_TOMCAT_MAXTHREADS` (default: 100) * `ATL_TOMCAT_MINSPARETHREADS` (default: 10) * `ATL_TOMCAT_CONNECTIONTIMEOUT` (default: 20000) * `ATL_TOMCAT_ENABLELOOKUPS` (default: false) * `ATL_TOMCAT_PROTOCOL` (default: HTTP/1.1) * `ATL_TOMCAT_ACCEPTCOUNT` (default: 10) * `ATL_TOMCAT_MAXHTTPHEADERSIZE` (default: 8192) ### Access Log Settings You 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. * `ATL_TOMCAT_ACCESS_LOGS_MAXDAYS` (default: -1) ### JVM Configuration If 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 * `JVM_SUPPORT_RECOMMENDED_ARGS` Additional JVM arguments for Crowd ??? example `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` ### Data Center configuration This docker image can be run as part of a [Data Center][4] cluster. You can specify the following properties to start Crowd as a Data Center node, instead of manually configuring a cluster. See [Installing Crowd Data Center][5] for more information. ### Container Configuration * `SET_PERMISSIONS` (default: true) Define whether to set home directory permissions on startup. Set to `false` to disable this behaviour. ### Advanced Configuration As mentioned at the top of this section, the settings from the environment are used to populate the application configuration on the container startup. However, in some cases you may wish to customise the settings in ways that are not supported by the environment variables above. In this case, it is possible to modify the base templates to add your own configuration. There are three main ways of doing this; modify our repository to your own image, build a new image from the existing one, or provide new templates at startup. We will briefly outline these methods here, but in practice how you do this will depend on your needs. ##### Building your own image * Clone the Atlassian repository at https://bitbucket.org/atlassian-docker/docker-atlassian-crowd/ * Modify or replace the [Jinja](https://jinja.palletsprojects.com/) templates under `config`; _NOTE_: The files must have the `.j2` extensions. However you don't have to use template variables if you don't wish. * Build the new image with e.g: `docker build --tag my-crowd-image --build-arg CROWD_VERSION=3.x.x .` * Optionally push to a registry, and deploy. ##### Build a new image from the existing one * Create a new `Dockerfile`, which starts with the Atlassian Crowd base image e.g: `FROM atlassian/crowd:latest`. * Use a `COPY` line to overwrite the provided templates. * Build, push and deploy the new image as above. ##### Overwrite the templates at runtime There are two main ways of doing this: * If your container is going to be long-lived, you can create it, modify the installed templates under `/opt/atlassian/etc/`, and then run it. * Alternatively, you can create a volume containing your alternative templates, and mount it over the provided templates at runtime with `--volume my-config:/opt/atlassian/etc/`. ## Shared directory and user IDs By default the Crowd application runs as the user `crowd`, with a UID and GID of 2004. Consequently this UID must have write access to the shared filesystem. If for some reason a different UID must be used, there are a number of options available: * The Docker image can be rebuilt with a different UID. * Under Linux, the UID can be remapped using [user namespace remapping][7]. To preserve strict permissions for certain configuration files, this container starts as `root` to perform bootstrapping before running Crowd under a non-privileged user account. If you wish to start the container as a non-root user, please note that Tomcat configuration will be skipped and a warning will be logged. You may still apply custom configuration in this situation by mounting configuration files directly, e.g. by mounting your own server.xml file directly to `/opt/atlassian/crowd/apache-tomcat/conf/server.xml` ## Upgrade To 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: ```shell docker stop crowd docker rm crowd docker run ... (See above) ``` As your data is stored in the data volume directory on the host it will still be available after the upgrade. !!! note "Please make sure that you **don't** accidentally remove the `crowd` container and its volumes using the `-v` option." ## Backup For 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. If 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. Read more about data recovery and backups: [Backing Up and Restoring Data][6] ## Versioning The `latest` tag matches the most recent release of Atlassian Crowd. Thus `atlassian/crowd:latest` will use the newest version of Crowd available. Alternatively you can use a specific major, major.minor, or major.minor.patch version of Crowd by using a version number tag: * `atlassian/crowd:3` * `atlassian/crowd:3.2` * `atlassian/crowd:3.2.3` All versions from 3.0+ are available ## Supported JDK versions and base images All Atlassian Crowd Docker images are now JDK11 only, and generated from the [official Eclipse Temurin OpenJDK Docker images](https://hub.docker.com/_/eclipse-temurin). Starting from 5.2.3 [UBI based](https://catalog.redhat.com/software/containers/ubi9/openjdk-11-runtime/61ee7d1c33f211c45407a91c) tags are published as well. UBI tags are available in 2 formats: `-ubi9` and `-ubi9-jdk11`. The Docker images follow the [Atlassian Support end-of-life policy](https://confluence.atlassian.com/support/atlassian-support-end-of-life-policy-201851003.html); images for unsupported versions of the products remain available but will no longer receive updates or fixes. Historically, we have also generated other versions of the images, including JDK8, Alpine, and 'slim' versions of the JDK. These legacy images still exist in Docker Hub, however they should be considered deprecated, and do not receive updates or fixes. If for some reason you need a different version, see "Building your own image" above. ## Migration to UBI If 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`. Also, 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). ## Supported architectures Currently, Crowd container images are built for the `linux/amd64` and `linux/arm64` target platforms. The Dockerfiles and support tooling have now had all architecture-specific components removed, so if necessary it is possible to build images for any platform supported by OCI-compliant container runtimes. ### Building on the target architecture Note: This method is known to work on Mac M1 and AWS ARM64 machines, but has not been extensively tested. The simplest method of getting a platform image is to build it on a target machine. The following assumes you have git and Docker installed. You will also need to know which version of Crowd you want to build; substitute `CROWD_VERSION=x.x.x` with your required version: ```shell git clone --recurse-submodule https://bitbucket.org/atlassian-docker/docker-atlassian-crowd.git cd docker-atlassian-crowd docker build --tag my-image --build-arg CROWD_VERSION=x.x.x . ``` This image can be pushed up to your own Docker Hub or private repository. ## Troubleshooting These images include built-in scripts to assist in performing common JVM diagnostic tasks. ### Thread dumps `/opt/atlassian/support/thread-dumps.sh` can be run via `docker exec` to easily trigger the collection of thread dumps from the containerized application. For example: ```shell docker exec my_crowd /opt/atlassian/support/thread-dumps.sh ``` By default this script will collect 10 thread dumps at 5 second intervals. This can be overridden by passing a custom value for the count and interval, by using `-c` / `--count` and `-i` / `--interval` respectively. For example, to collect 20 thread dumps at 3 second intervals: ```shell docker exec my_container /opt/atlassian/support/thread-dumps.sh --count 20 --interval 3 ``` Thread dumps will be written to `$APP_HOME/thread_dumps/`. ???+ note "Disable capturing output from top run" By default this script will also capture output from top run in 'Thread-mode'. This can be disabled by passing `-n` / `--no-top` ### Heap dump `/opt/atlassian/support/heap-dump.sh` can be run via `docker exec` to easily trigger the collection of a heap dump from the containerized application. For example: ```shell docker exec my_container /opt/atlassian/support/heap-dump.sh ``` A heap dump will be written to `$APP_HOME/heap.bin`. If a file already exists at this location, use `-f` / `--force` to overwrite the existing heap dump file. ### Manual diagnostics The `jcmd` utility is also included in these images and can be used by starting a `bash` shell in the running container: ```shell docker exec -it my_container /bin/bash ``` ## Support For product support, go to: * https://support.atlassian.com/crowd/ You can also visit the [Atlassian Data Center](https://community.atlassian.com/t5/Atlassian-Data-Center-on/gh-p/DC_Kubernetes) forum for discussion on running Atlassian Data Center products in containers. ## Changelog For a detailed list of changes to the Docker image configuration see [the Git commit history](https://bitbucket.org/atlassian-docker/docker-atlassian-crowd/commits/). ## License Copyright © 2019 Atlassian Corporation Pty Ltd. Licensed under the Apache License, Version 2.0. [1]: https://www.atlassian.com/software/crowd [2]: https://confluence.atlassian.com/crowd/supported-platforms-191851.html [3]: https://confluence.atlassian.com/crowd031/integrating-crowd-with-apache-949753124.html [4]: https://confluence.atlassian.com/crowd/crowd-data-center-935372453.html [5]: https://confluence.atlassian.com/crowd/installing-crowd-data-center-935369773.html [6]: https://confluence.atlassian.com/crowd/backing-up-and-restoring-data-36470797.html [7]: https://docs.docker.com/engine/security/userns-remap/ ================================================ FILE: docs/docs/containers/JIRA.md ================================================ # ![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 ## Overview Jira Software Data Center helps the world’s best agile teams plan, track, and release great software at scale. * Check out [atlassian/jira-software](http://hub.docker.com/r/atlassian/jira-software/) on Docker Hub * Learn more about Jira Software: [https://www.atlassian.com/software/jira](https://www.atlassian.com/software/jira) Jira Service Management Data Center is an enterprise ITSM solution that offers high availability, meeting your security and compliance needs so no request goes unresolved. * Check out [atlassian/jira-servicemanagement](http://hub.docker.com/r/atlassian/jira-servicemanagement/) on Docker Hub * Learn more about Jira Service Management: [https://www.atlassian.com/software/jira/service-management](https://www.atlassian.com/software/jira/service-management) Jira Core is a project and task management solution built for business teams. * Check out [atlassian/jira-core](http://hub.docker.com/r/atlassian/jira-core/) on Docker Hub * Learn more about Jira Core: [https://www.atlassian.com/software/jira/core](https://www.atlassian.com/software/jira/core) This Docker container makes it easy to get an instance of Jira Software, Service Management or Core up and running. Note: Jira Software will be referenced in the examples provided. **Use docker version >= 20.10.10** ## Quick Start For the `JIRA_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. Additionally, if running Jira in Data Center mode it is required that a shared filesystem is mounted. The mount point (inside the container) can be configured with `JIRA_SHARED_HOME`. To get started you can use a data volume, or named volumes. In this example we'll use named volumes. ```shell docker volume create --name jiraVolume docker run -v jiraVolume:/var/atlassian/application-data/jira --name="jira" -d -p 8080:8080 atlassian/jira-software ``` !!! success "Jira is now available on [http://localhost:8080](http://localhost:8080)." Please ensure your container has the necessary resources allocated to it. We recommend 2GiB of memory allocated to accommodate the application server. See [System Requirements](https://confluence.atlassian.com/adminjiraserver071/jira-applications-installation-requirements-802592164.html) for further information. ???+ tip "If you are using `docker-machine` on Mac OS X, please use `open http://$(docker-machine ip default):8080` instead." ## Configuring Jira This Docker image is intended to be configured from its environment; the provided information is used to generate the application configuration files from templates. This allows containers to be repeatably created and destroyed on-the-fly, as required in advanced cluster configurations. Most aspects of the deployment can be configured in this manner; the necessary environment variables are documented below. However, if your particular deployment scenario is not covered by these settings, it is possible to override the provided templates with your own; see the section [Advanced Configuration](#advanced-configuration) below. ### Verbose container entrypoint logging During the startup process of the container, various operations and checks are performed to ensure that the application is configured correctly and ready to run. To help in troubleshooting and to provide transparency into this process, you can enable verbose logging. The `VERBOSE_LOGS` environment variable enables detailed debug messages to the container's log, offering insights into the actions performed by the entrypoint script. * `VERBOSE_LOGS` (default: false) Set to `true` to enable detailed debug messages during the container initialization. ### Memory / Heap Size If 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. * `JVM_MINIMUM_MEMORY` (default: 384m) The minimum heap size of the JVM * `JVM_MAXIMUM_MEMORY` (default: 768m) The maximum heap size of the JVM * `JVM_RESERVED_CODE_CACHE_SIZE` (default: 512m) The reserved code cache size of the JVM ### Reverse Proxy Settings If Jira is run behind a reverse proxy server (e.g. a load-balancer or nginx server) as [described here](https://confluence.atlassian.com/adminjiraserver072/integrating-jira-with-apache-using-ssl-828788158.html), then you need to specify extra options to make Jira aware of the setup. They can be controlled via the below environment variables. * `ATL_PROXY_NAME` (default: NONE) The reverse proxy's fully qualified hostname. `CATALINA_CONNECTOR_PROXYNAME` is also supported for backwards compatability. * `ATL_PROXY_PORT` (default: NONE) The reverse proxy's port number via which Jira is accessed. `CATALINA_CONNECTOR_PROXYPORT` is also supported for backwards compatability. * `ATL_TOMCAT_PORT` (default: 8080) The port for Tomcat/Jira to listen on. Depending on your container deployment method this port may need to be [exposed and published][docker-expose]. * `ATL_TOMCAT_SCHEME` (default: http) The protocol via which Jira is accessed. `CATALINA_CONNECTOR_SCHEME` is also supported for backwards compatability. * `ATL_TOMCAT_SECURE` (default: false) Set 'true' if `ATL_TOMCAT_SCHEME` is 'https'. `CATALINA_CONNECTOR_SECURE` is also supported for backwards compatability. * `ATL_TOMCAT_CONTEXTPATH` (default: NONE) The context path the application is served over. `CATALINA_CONTEXT_PATH` is also supported for backwards compatability. * `ATL_TOMCAT_REQUESTATTRIBUTESENABLED` Checks for the existence of request attributes (typically set by the RemoteIpValve and similar) that should be used to override the values returned by the request for remote address, remote host, server port and protocol. This property is usually combined with `ATL_TOMCAT_TRUSTEDPROXIES` and `ATL_TOMCAT_INTERNALPROXIES` to show IP address of the remote host instead of the load balancer's. If not declared, the default value of `false` will be used. * `ATL_TOMCAT_TRUSTEDPROXIES` A list of IP addresses separated by a pipe character e.g. `10.0.9.6|10.0.9.32`. Trusted proxies that appear in the `remoteIpHeader` will be trusted and *will appear* in the `proxiesHeader` value. By adding a list of Trusted Proxies, Confluence will remove the load balancers' IP addresses from Confluence's view of the incoming connection. This could be desired in a clustered load balancer architecture where the load balancer address changes depending on which node proxies the connection. If not specified, no trusted proxies will be trusted. * `ATL_TOMCAT_INTERNALPROXIES` A list of IP addresses separated by a pipe character e.g. `10.0.9.6|10.0.9.32`. Trusted proxies that appear in the `remoteIpHeader` will be trusted and *will not appear* in the `proxiesHeader` value. By adding a list of Internal Proxies, Confluence will remove the load balancers' IP addresses from Confluence's view of the incoming connection. This could be desired in a clustered load balancer architecture where the load balancer address changes depending on which node proxies the connection. If not specified, no internal proxies will be trusted. * `ATL_TOMCAT_ADDITIONAL_CONNECTOR_PORT` - If unset, no additional connector is defined in server.xml. No default. * `ATL_TOMCAT_ADDITIONAL_CONNECTOR_CONNECTION_TIMEOUT` (default: 20000) * `ATL_TOMCAT_ADDITIONAL_CONNECTOR_MAX_THREADS` (default: 50) * `ATL_TOMCAT_ADDITIONAL_CONNECTOR_MIN_SPARE_THREADS` (default: 10) * `ATL_TOMCAT_ADDITIONAL_CONNECTOR_ENABLE_LOOKUPS` (default: false) * `ATL_TOMCAT_ADDITIONAL_CONNECTOR_ACCEPT_COUNT` (default: 10) * `ATL_TOMCAT_ADDITIONAL_CONNECTOR_URI_ENCODING` (default: UTF-8) * `ATL_TOMCAT_ADDITIONAL_CONNECTOR_SECURE` (no default, if undefined secure is not set in the connector) The following Tomcat/Catalina options are also supported. For more information, see https://tomcat.apache.org/tomcat-7.0-doc/config/index.html. * `ATL_TOMCAT_MGMT_PORT` (default: 8005) * `ATL_TOMCAT_MAXTHREADS` (default: 100) * `ATL_TOMCAT_MINSPARETHREADS` (default: 10) * `ATL_TOMCAT_CONNECTIONTIMEOUT` (default: 20000) * `ATL_TOMCAT_ENABLELOOKUPS` (default: false) * `ATL_TOMCAT_PROTOCOL` (default: HTTP/1.1) * `ATL_TOMCAT_ACCEPTCOUNT` (default: 10) * `ATL_TOMCAT_MAXHTTPHEADERSIZE` (default: 8192) * `ATL_TOMCAT_STUCKTHREADDETECTIONVALVE_THRESHOLD` (default: 120) ### Access Log Settings You 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. * `ATL_TOMCAT_ACCESS_LOGS_MAXDAYS` (default: -1) * `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"`) ### JVM configuration If 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 * `JVM_SUPPORT_RECOMMENDED_ARGS` Additional JVM arguments for Jira ??? example `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` ### Jira-specific settings * `ATL_AUTOLOGIN_COOKIE_AGE` (default: 1209600; two weeks, in seconds) The maximum time a user can remain logged-in with 'Remember Me'. ### S3 Avatars storage configuration Starting with Jira 9.9, you can configure Jira to store avatar files in Amazon S3. For requirements and additional information, 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). * `ATL_S3AVATARS_BUCKET_NAME` Bucket name to store avatars. * `ATL_S3AVATARS_REGION` AWS region where the S3 bucket is located. * `ATL_S3AVATARS_ENDPOINT_OVERRIDE` Override the default AWS API endpoint with a custom one (optional). ### OpenSearch configuration Starting with Jira 11.2, you can configure Jira to use OpenSearch as the search platform. For the full list of available OpenSearch properties and requirements, see [Configuring OpenSearch for Jira](https://confluence.atlassian.com/adminjiraserver/configuring-opensearch-for-jira-1620511851.html). OpenSearch properties are injected into `jira-config.properties` using `ADDITIONAL_JIRA_CONFIG_*` environment variables (see [Custom `jira-config.properties`](#custom-jira-configproperties) for details on the mechanism). The minimum required properties are: * `search.platform` The search platform to use. Set to `opensearch` to enable OpenSearch. * `opensearch.http.url` HTTP(S) URL of the OpenSearch cluster, or multiple URLs separated by commas. * `opensearch.username` Username for the OpenSearch cluster. * `opensearch.password` Password for the OpenSearch cluster. The `__EXPAND_ENV` suffix lets you keep the password in a separate environment variable rather than embedding it directly in the property line. In the example below `MY_OPENSEARCH_PASSWORD` is passed inline for brevity: ```bash docker run \ -e MY_OPENSEARCH_PASSWORD=my-secret \ -e ADDITIONAL_JIRA_CONFIG_01="search.platform=opensearch" \ -e ADDITIONAL_JIRA_CONFIG_02="opensearch.http.url=http://opensearch-host:9200" \ -e ADDITIONAL_JIRA_CONFIG_03="opensearch.username=admin" \ -e ADDITIONAL_JIRA_CONFIG_04__EXPAND_ENV="opensearch.password={MY_OPENSEARCH_PASSWORD}" \ atlassian/jira-software:latest ``` !!! warning "Sensitive values on the command line" Passing secrets via `-e` exposes them in shell history, process listings, and `docker inspect` output. In production, use `--env-file` with a permission-protected file or an external secrets manager to supply `MY_OPENSEARCH_PASSWORD`. ### S3 Attachments storage configuration Starting 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 information, 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). * `ATL_S3ATTACHMENTS_BUCKET_NAME` Bucket name to store avatars. * `ATL_S3ATTACHMENTS_REGION` AWS region where the S3 bucket is located. * `ATL_S3ATTACHMENTS_ENDPOINT_OVERRIDE` Override the default AWS API endpoint with a custom one (optional). Avatars 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. ### S3 Backups storage configuration Starting 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). * `ATL_S3BACKUPS_BUCKET_NAME` Bucket name to store avatars. * `ATL_S3BACKUPS_REGION` AWS region where the S3 bucket is located. * `ATL_S3BACKUPS_ENDPOINT_OVERRIDE` Override the default AWS API endpoint with a custom one (optional). ### Database configuration It is optionally possible to configure the database from the environment, avoiding the need to do so through the web startup screen. The following variables are all must all be supplied if using this feature: * `ATL_JDBC_URL` The database URL; this is database-specific. * `ATL_JDBC_USER` The database user to connect as. * `ATL_JDBC_PASSWORD` The password for the database user. * `ATL_DB_DRIVER` The JDBC driver class; supported drivers are: * `com.microsoft.sqlserver.jdbc.SQLServerDriver` * `com.mysql.jdbc.Driver` * `oracle.jdbc.OracleDriver` * `org.postgresql.Driver` The driver must match the DB type (see next entry). * `ATL_DB_TYPE` The type of database; valid supported values are: * `mssql` * `mysql` * `mysql57` * `mysql8` * `oracle10g` * `postgres72` ???+ note "MySQL supportability" `mysql` is only supported for versions prior to 8.13, and `mysql57` and `mysql8` are only supported after. See [the 8.13.x upgrade instructions](https://confluence.atlassian.com/jirasoftware/jira-software-8-13-x-upgrade-notes-1018783378.html) for details. The following variables may be optionally supplied when configuring the database from the environment: * `ATL_DB_SCHEMA_NAME` The schema name of the database. Depending on the value of `ATL_DB_TYPE`, the following default values are used if no schema name is specified: * `mssql`: `dbo` * `mysql`: NONE * `mysql57`: NONE * `mysql8`: NONE * `oracle10g`: NONE * `postgres72`: `public` ???+ note "MySQL or Oracle JDBC drivers" Due to licensing restrictions Jira does not ship with MySQL or Oracle JDBC drivers. To use these databases you will need to copy a suitable driver into the container and restart it. For example, to copy the MySQL driver into a container named "jira", you would do the following: `docker cp mysql-connector-java.x.y.z.jar jira:/opt/atlassian/jira/lib` `docker restart jira` For more information see the page [Startup check: JIRA database driver missing](https://confluence.atlassian.com/jirakb/startup-check-jira-database-driver-missing-873872169.html). #### Optional database settings * `ATL_JDBC_SECRET_CLASS` [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. Starting from 9.11 [AWS SecretsManager](https://confluence.atlassian.com/adminjiraserver/configuring-aws-secrets-manager-1282250155.html) is supported. **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 which will force the image entrypoint to regenerate `dbconfig.xml` with the new properties. Other database environment variables must be also set in the container: ```shell docker run -v jiraVolume:/var/atlassian/application-data/jira --name='jira' -d -p 8080:8080 \ -e ATL_JDBC_URL=jdbc:postgresql://172.17.0.1:5432/jira \ -e ATL_JDBC_USER='jira' -e ATL_DB_DRIVER='org.postgresql.Driver' \ -e ATL_DB_TYPE='postgres72' \ -e ATL_JDBC_SECRET_CLASS='com.atlassian.secrets.store.aws.AwsSecretsManagerStore' \ -e ATL_JDBC_PASSWORD='{"region": "us-east-1", "secretId": "mysecret", "secretPointer": "/password"}' \ -e ATL_FORCE_CFG_UPDATE='true' atlassian/jira-software ``` The following variables are for the Tomcat JDBC connection pool, and are optional. For more information on these see: https://tomcat.apache.org/tomcat-7.0-doc/jdbc-pool.html * `ATL_DB_MAXIDLE` (default: 20) * `ATL_DB_MAXWAITMILLIS` (default: 30000) * `ATL_DB_MINEVICTABLEIDLETIMEMILLIS` (default: 5000) * `ATL_DB_MINIDLE` (default: 10) * `ATL_DB_POOLMAXSIZE` (default: 100) * `ATL_DB_POOLMINSIZE` (default: 20) * `ATL_DB_REMOVEABANDONED` (default: true) * `ATL_DB_REMOVEABANDONEDTIMEOUT` (default: 300) * `ATL_DB_TESTONBORROW` (default: false) * `ATL_DB_TESTWHILEIDLE` (default: true) * `ATL_DB_TIMEBETWEENEVICTIONRUNSMILLIS` (default: 30000) * `ATL_DB_VALIDATIONQUERY` (default: select 1) The following settings only apply when using the Postgres driver: * `ATL_DB_KEEPALIVE` (default: true) * `ATL_DB_SOCKETTIMEOUT` (default: 240) The following settings only apply when using the MySQL driver: * `ATL_DB_VALIDATIONQUERYTIMEOUT` (default: 3) ### Data Center configuration This docker image can be run as part of a [Data Center](https://confluence.atlassian.com/enterprise/jira-data-center-472219731.html) cluster. You can specify the following properties to start Jira as a Data Center node, instead of manually configuring a cluster.properties file, See [Installing Jira Data Center](https://confluence.atlassian.com/adminjiraserver071/installing-jira-data-center-802592197.html) for more information on each property and its possible configuration. #### Cluster configuration *Jira Software and Jira Service Management only* * `CLUSTERED` (default: false) Set 'true' to enable clustering configuration to be used. This will create a `cluster.properties` file inside the container's `$JIRA_HOME` directory. * `JIRA_NODE_ID` (default: jira_node_) The unique ID for the node. By default, this includes a randomly generated ID unique to each container, but can be overridden with a custom value. * `JIRA_SHARED_HOME` (default: $JIRA_HOME/shared) The location of the shared home directory for all Jira nodes. **Note**: This must be real shared filesystem that is mounted inside the container. Additionally, see the note about UIDs. * `EHCACHE_PEER_DISCOVERY` (default: default) Describes how nodes find each other. * `EHCACHE_LISTENER_HOSTNAME` (default: NONE) The hostname of the current node for cache communication. Jira Data Center will resolve this this internally if the parameter isn't set. * `EHCACHE_LISTENER_PORT` (default: 40001) The port the node is going to be listening to. Depending on your container deployment method this port may need to be [exposed and published][docker-expose]. * `EHCACHE_OBJECT_PORT` (default: dynamic) The port number on which the remote objects bound in the registry receive calls. This defaults to a free port if not specified. This port may need to be [exposed and published][docker-expose]. * `EHCACHE_LISTENER_SOCKETTIMEOUTMILLIS` (default: 2000) The default timeout for the Ehcache listener. * `EHCACHE_MULTICAST_ADDRESS` (default: NONE) A valid multicast group address. Required when EHCACHE_PEER_DISCOVERY is set to 'automatic' instead of 'default'. * `EHCACHE_MULTICAST_PORT` (default: NONE) The dedicated port for the multicast heartbeat traffic. Required when EHCACHE_PEER_DISCOVERY is set to 'automatic' instead of 'default'. Depending on your container deployment method this port may need to be [exposed and published][docker-expose]. * `EHCACHE_MULTICAST_TIMETOLIVE` (default: NONE) A value between 0 and 255 which determines how far the packets will propagate. Required when EHCACHE_PEER_DISCOVERY is set to 'automatic' instead of 'default'. * `EHCACHE_MULTICAST_HOSTNAME` (default: NONE) The hostname or IP of the interface to be used for sending and receiving multicast packets. Required when EHCACHE_PEER_DISCOVERY is set to 'automatic' instead of 'default'. #### Shared directory and user IDs By default, the Jira application runs as the user `jira`, with a UID and GID of 2001. Consequently, this UID must have write access to the shared filesystem. If for some reason a different UID must be used, there are a number of options available: * The Docker image can be rebuilt with a different UID. * Under Linux, the UID can be remapped using [user namespace remapping](https://docs.docker.com/engine/security/userns-remap/). To preserve strict permissions for certain configuration files, this container starts as `root` to perform bootstrapping before running Jira under a non-privileged user account. If you wish to start the container as a non-root user, please note that Tomcat configuration will be skipped and a warning will be logged. You may still apply custom configuration in this situation by mounting a custom server.xml file directly to `/opt/atlassian/jira/conf/server.xml` Database and Clustering bootstrapping will work as expected when starting this container as a non-root user. ### Container configuration * `ATL_FORCE_CFG_UPDATE` (default: false) The Docker [entrypoint][entrypoint.py] generates application configuration on first start; not all of these files are regenerated on subsequent starts. This is deliberate, to avoid race conditions or overwriting manual changes during restarts and upgrades. However in deployments where configuration is purely specified through the environment (e.g. Kubernetes) this behaviour may be undesirable; this flag forces an update of all generated files. In Jira the affected files are: `dbconfig.xml` See [the entrypoint code][entrypoint.py] for the details of how configuration files are generated. * `ATL_ALLOWLIST_SENSITIVE_ENV_VARS` 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. ???+ warning "Value exposure on host OS" When using this property, the values to sensitive environment variables will be available in clear text on the host OS. As such, this data may be exposed to users or processes running on the host OS. * `SET_PERMISSIONS` (default: true) Define whether to set home directory permissions on startup. Set to `false` to disable this behaviour. * `ATL_UNSET_SENSITIVE_ENV_VARS` (default: true) Define whether to unset environment variables containing keywords 'PASS', 'SECRET' or 'TOKEN'. The unset function is executed in the entrypoint. Set to `false` if you want to allow passing sensitive environment variables to Jira container. ???+ warning "Value exposure on host OS" When using this property, the values to sensitive environment variables will be available in clear text on the host OS. As such, this data may be exposed to users or processes running on the host OS. * `ATL_JIRA_CLEAR_PLUGIN_CACHE` When set to true, plugin cache at `${JIRA_HOME}/plugins/.bundled-plugins` and `${JIRA_HOME}/plugins/.osgi-plugins` 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 every time the container starts. See: [How to clear Jira's plugin cache](https://confluence.atlassian.com/jirakb/how-to-clear-jira-s-plugin-cache-1157468195.html). * `ATL_JIRA_SESSION_TIMEOUT` The default Tomcat session timeout (in minutes) for all newly created sessions which is set in web.xml. Defaults to 30. ### Custom `jira-config.properties` Additional properties can be injected into `jira-config.properties` using environment variables prefixed with `ADDITIONAL_JIRA_CONFIG_`. Each variable's value must be a complete property line in `key=value` format. Environment variable names are sorted for consistent file generation; order has no effect on runtime behavior. ```bash docker run \ -e ADDITIONAL_JIRA_CONFIG_01="jira.websudo.is.disabled=true" \ -e ADDITIONAL_JIRA_CONFIG_02="jira.lf.top.bgcolour=#003366" \ atlassian/jira-software:latest ``` #### How properties are written The properties are written to a clearly marked auto-generated section at the end of the file. Any manually added content outside this section is preserved across container restarts. #### Injecting secrets via `__EXPAND_ENV` For values that reference secrets stored in separate environment variables (common in Kubernetes where secrets are mounted as env vars), use the `__EXPAND_ENV` suffix. Placeholders in `{VAR_NAME}` format are replaced with the corresponding environment variable value at startup: ```bash docker run \ -e MY_OPENSEARCH_PASSWORD=my-secret \ -e ADDITIONAL_JIRA_CONFIG_01="search.platform=opensearch" \ -e ADDITIONAL_JIRA_CONFIG_02__EXPAND_ENV="opensearch.password={MY_OPENSEARCH_PASSWORD}" \ atlassian/jira-software:latest ``` This generates the following in `jira-config.properties`: ```properties # ---- AUTO GENERATED ADDITIONAL PROPERTIES FROM DOCKER IMAGE --- # DO NOT MODIFY this section - it is auto-generated during container startup # from ADDITIONAL_JIRA_CONFIG_* environment variables search.platform=opensearch opensearch.password=my-secret # ---- END OF AUTO GENERATED ADDITIONAL PROPERTIES --- ``` If a referenced environment variable is not set, the placeholder is left unchanged and a warning is logged. #### Limitations and requirements * **Local home directory only**: `jira-config.properties` is written to `$JIRA_HOME` which must be the node-local home directory (not shared storage). Using `ADDITIONAL_JIRA_CONFIG_*` when `jira-config.properties` is stored on a shared filesystem (e.g. NFS, EFS) may cause unexpected outcomes due to update races across different container instances during rolling deployments. * **Read-only mounts not supported**: If `jira-config.properties` is mounted as a read-only file (e.g. via a Kubernetes ConfigMap volume mount), the `ADDITIONAL_JIRA_CONFIG_*` variables will have no effect. A warning is logged in this case. Manage the file content entirely through the mount instead — do not combine both approaches. * **Auto-generated section**: The generated properties are placed inside clearly marked comment boundaries at the end of the file. Manual edits outside these markers are preserved. Do not edit content within the markers — it will be overwritten on the next container startup. | Aspect | Detail | |-------------------------|-------------------------------------------------------------| | Env var prefix | `ADDITIONAL_JIRA_CONFIG_` | | Secret expansion suffix | `__EXPAND_ENV` (double underscore) | | Target file | `$JIRA_HOME/jira-config.properties` | | Ordering | Sorted for reproducibility; order has no effect on behavior | | Existing content | Preserved (only auto-generated section is replaced) | | No matching env vars | File is not created; stale section is removed if present | ### Advanced Configuration As mentioned at the top of this section, the settings from the environment are used to populate the application configuration on the container startup. However, in some cases you may wish to customise the settings in ways that are not supported by the environment variables above. In this case, it is possible to modify the base templates to add your own configuration. There are three main ways of doing this; modify our repository to your own image, build a new image from the existing one, or provide new templates at startup. We will briefly outline these methods here, but in practice how you do this will depend on your needs. ##### Building your own image * Clone the Atlassian repository at https://bitbucket.org/atlassian-docker/docker-atlassian-jira/ * Modify or replace the [Jinja](https://jinja.palletsprojects.com/) templates under `config`; _NOTE_: The files must have the `.j2` extensions. However you don't have to use template variables if you don't wish. * Build the new image with e.g: `docker build --tag my-jira-8-image --build-arg JIRA_VERSION=8.x.x .` * Optionally push to a registry, and deploy. ##### Build a new image from the existing one * Create a new `Dockerfile`, which starts with the line e.g: `FROM atlassian/jira-software:latest`. * Use a `COPY` line to overwrite the provided templates. * Build, push and deploy the new image as above. ##### Overwrite the templates at runtime There are two main ways of doing this: * If your container is going to be long-lived, you can create it, modify the installed templates under `/opt/atlassian/etc/`, and then run it. * Alternatively, you can create a volume containing your alternative templates, and mount it over the provided templates at runtime with `--volume my-config:/opt/atlassian/etc/`. ## Logging By default the Jira logs are written inside the container, under `${JIRA_HOME}/logs/`. If you wish to expose this outside the container (e.g. to be aggregated by logging system) this directory can be a data volume or bind mount. Additionally, Tomcat-specific logs are written to `/opt/atlassian/jira/logs/`. ## Upgrades To 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: ```shell docker stop jira docker rm jira docker run ... (See above) ``` As your data is stored in the data volume directory on the host it will still be available after the upgrade. !!! note "Please make sure that you **don't** accidentally remove the `jira` container and its volumes using the `-v` option." ## Backup For 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. If 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. Read 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) ## Shutdown Depending on your configuration Jira may take a short period to shutdown any active operations to finish before termination. If sending a `docker stop` this should be taken into account with the `--time` flag. Alternatively, the script `/shutdown-wait.sh` is provided, which will initiate a clean shutdown and wait for the process to complete. This is the recommended method for shutdown in environments which provide for orderly shutdown, e.g. Kubernetes via the `preStop` hook. ## Versioning The `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. Alternatively you can use a specific major, major.minor, or major.minor.patch version of Jira by using a version number tag: * `atlassian/jira-software:8` * `atlassian/jira-software:8.14` * `atlassian/jira-software:8.14.0` * `atlassian/jira-servicemanagement:4` * `atlassian/jira-servicemanagement:4.14` * `atlassian/jira-servicemanagement:4.14.0` * `atlassian/jira-core:8` * `atlassian/jira-core:8.14` * `atlassian/jira-core:8.14.0` All Jira versions from 7.13+ (Software/Core) / 3.16+ (Service Management) are available. ???+ warning "`atlassian/jira-servicedesk` deprecation" All Jira Service Management 4.x versions are also available as `atlassian/jira-servicedesk`. This namespace has been deprecated and versions from 5+ onwards will only be available as `atlassian/jira-servicemanagement`. ## Supported JDK versions and base images Atlassian Docker images are generated from either [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). UBI based images are only published from Jira 9.5 onwards and JDK17 only. Tags are available in 2 formats: `-ubi9` and `-ubi9-jdk17`. The Docker images follow the [Atlassian Support end-of-life policy](https://confluence.atlassian.com/support/atlassian-support-end-of-life-policy-201851003.html); images for unsupported versions of the products remain available but will no longer receive updates or fixes. Historically, we have also generated other versions of the images, including JDK8, Alpine, and 'slim' versions of the JDK. These legacy images still exist in Docker Hub, however they should be considered deprecated, and do not receive updates or fixes. If for some reason you need a different version, see [Building your own image](#building-your-own-image) above. ## Migration to UBI If 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`. Also, 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). ## Supported architectures Currently, Jira and JSM container images are built for the `linux/amd64` and `linux/arm64` target platforms. The Dockerfiles and support tooling have now had all architecture-specific components removed, so if necessary it is possible to build images for any platform supported by OCI-compliant container runtimes. ### Building on the target architecture Note: This method is known to work on Mac M1 and AWS ARM64 machines, but has not been extensively tested. The simplest method of getting a platform image is to build it on a target machine. The following assumes you have git and Docker installed. You will also need to know which version of Jira you want to build; substitute `JIRA_VERSION=x.x.x` with your required version: ```shell git clone --recurse-submodule https://bitbucket.org/atlassian-docker/docker-atlassian-jira.git cd docker-atlassian-jira docker build --tag my-image --build-arg JIRA_VERSION=x.x.x . ``` This image can be pushed up to your own Docker Hub or private repository. ## Troubleshooting These images include built-in scripts to assist in performing common JVM diagnostic tasks. ### Thread dumps `/opt/atlassian/support/thread-dumps.sh` can be run via `docker exec` to easily trigger the collection of thread dumps from the containerized application. For example: ```shell docker exec my_container /opt/atlassian/support/thread-dumps.sh ``` By default, this script will collect 10 thread dumps at 5 second intervals. This can be overridden by passing a custom value for the count and interval, by using `-c` / `--count` and `-i` / `--interval` respectively. For example, to collect 20 thread dumps at 3 second intervals: ```shell docker exec my_container /opt/atlassian/support/thread-dumps.sh --count 20 --interval 3 ``` Thread dumps will be written to `$APP_HOME/thread_dumps/`. ???+ note "Disable capturing output from top run" By default this script will also capture output from top run in 'Thread-mode'. This can be disabled by passing `-n` / `--no-top` ### Heap dump `/opt/atlassian/support/heap-dump.sh` can be run via `docker exec` to easily trigger the collection of a heap dump from the containerized application. For example: ```shell docker exec my_container /opt/atlassian/support/heap-dump.sh ``` A heap dump will be written to `$APP_HOME/heap.bin`. If a file already exists at this location, use `-f` / `--force` to overwrite the existing heap dump file. ### Manual diagnostics The `jcmd` utility is also included in these images and can be used by starting a `bash` shell in the running container: ```shell docker exec -it my_container /bin/bash ``` ## Support For product support, go to: * https://support.atlassian.com/jira-software-server/ * https://support.atlassian.com/jira-service-management-server/ * https://support.atlassian.com/jira-core-server/ You can also visit the [Atlassian Data Center](https://community.atlassian.com/t5/Atlassian-Data-Center-on/gh-p/DC_Kubernetes) forum for discussion on running Atlassian Data Center products in containers. ## Development and testing See [Development][DEVELOPMENT.md] for details on setting up a development environment and running tests. ## Changelog For a detailed list of changes to the Docker image configuration see [the Git commit history](https://bitbucket.org/atlassian-docker/docker-atlassian-jira/commits/). ## License Copyright © 2020 Atlassian Corporation Pty Ltd. Licensed under the Apache License, Version 2.0. [docker-expose]: https://docs.docker.com/v17.09/engine/userguide/networking/default_network/binding/ [entrypoint.py]: https://bitbucket.org/atlassian-docker/docker-atlassian-jira/src/master/entrypoint.py [DEVELOPMENT.md]: https://bitbucket.org/atlassian-docker/docker-atlassian-jira/src/master/DEVELOPMENT.md ================================================ FILE: docs/docs/examples/.pages ================================================ collapse_single_pages: true nav: - EXAMPLES.md - Kubernetes cluster: cluster - database - ingress - storage - bamboo - bitbucket - confluence - jira - logging - ... ================================================ FILE: docs/docs/examples/EXAMPLES.md ================================================ # Available examples !!!warning "Support disclaimer" Use the examples we provide as reference only, we don’t offer official support for them. ## Pre-requisites ### :material-kubernetes: Kubernetes clusters See examples of provisioning Kubernetes clusters on cloud-based providers: * [Amazon EKS](cluster/EKS_SETUP.md) * [Google GKE](cluster/GKE_SETUP.md) * [Azure AKS](cluster/AKS_SETUP.md) ### :material-directions-fork: Ingress * See an example of [provisioning an NGINX Ingress controller](ingress/INGRESS_NGINX.md) ### :material-database: Database * See an example of [creating an Amazon RDS database instance](database/AMAZON_RDS.md) ### :material-folder-network: Storage === "AWS EBS" * See an example of [local storage utilizing AWS EBS-backed volumes](storage/aws/LOCAL_STORAGE.md) === "AWS EFS" * See an example of [shared storage utilizing AWS EFS-backed filesystem](storage/aws/SHARED_STORAGE.md) === "NFS" * See an example of [standing up an NFS server for Bitbucket](storage/nfs/NFS.md) ## Bamboo ### :material-lan-pending: Remote agents * See an example of deploying a [remote agent for Bamboo](bamboo/REMOTE_AGENTS.md) ## Bitbucket ### :material-file-search-outline: Elasticsearch * See an example of [standing up an Elasticsearch instance for Bitbucket](bitbucket/BITBUCKET_ELASTICSEARCH.md) ### :material-mirror-variant: Smart Mirrors * See an example of [Bitbucket Smart Mirrors](bitbucket/BITBUCKET_MIRRORS.md) ### :material-remote-desktop: SSH * See an example of [SSH service in Bitbucket on Kubernetes](bitbucket/BITBUCKET_SSH.md) ### :material-remote-desktop: Mesh * See an example of [Bitbucket Mesh on Kubernetes](bitbucket/BITBUCKET_MESH.md) ## Other ### :material-file-document-edit: Logging * See an example of [how to deploy an EFK stack to Kubernetes](logging/efk/EFK.md) ### :simple-prometheus: Prometheus Monitoring * See an example of [how to monitor DC products with Prometheus](../userguide/monitoring/PROMETHEUS.md) ### :material-checkbox-multiple-marked-outline: Customization * See an example of [External libraries and plugins](external_libraries/EXTERNAL_LIBS.md) ================================================ FILE: docs/docs/examples/bamboo/.pages ================================================ collapse_single_pages: false nav: - REMOTE_AGENTS.md - AGENT_CAPABILITIES.md - ... ================================================ FILE: docs/docs/examples/bamboo/AGENT_CAPABILITIES.md ================================================ # Agent capabilities A capability is a feature of an agent. A capability can be defined on an agent for: * an executable (e.g. Maven) * a JDK * a Version Control System client application (e.g. Git) You can learn more about remote agents capabilities on the [official documentation page](https://confluence.atlassian.com/bamboo/configuring-capabilities-289277148.html){.external}. ## Custom capabilities !!!info "Default capabilities" 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: * JDK 11 * Git & Git LFS * Maven 3 * Python 3 If 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. This custom image can be used, by first updating the Bamboo agent `values.yaml` with the image `tag` of the custom Docker image i.e. ```yaml image: repository: hoolicorp/bamboo-agent-base pullPolicy: IfNotPresent tag: "ruby-agent" ``` The custom agent can then be deployed via Helm: ```shell helm install ruby-agent atlassian-data-center/bamboo-agent -f ruby-agent.yaml ``` ================================================ FILE: docs/docs/examples/bamboo/REMOTE_AGENTS.md ================================================ # Remote agents Remote 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. You can learn more details about remote agents on the [official documentation page](https://confluence.atlassian.com/bamboo/agents-and-capabilities-289277114.html). ## Requirements !!!warning "Bamboo server prerequisites" * The Bamboo server instance must use a valid Bamboo Data Center instance license and be fully configured * The Bamboo server instance must have `security token verification` **enabled** * The Bamboo server instance must have `remote agent authentication` **disabled** ## Deployment Steps required for deploying a remote agent 1. Configure Bamboo server for remote agent support 2. Deploy agent ### 1. Configure Bamboo server There are 2 approaches for doing this: * Automatically when deploying Bamboo server * Manually via Bamboo server agent settings #### Automatically When initially deploying Bamboo server its `values.yaml` can be configured to: * disable `remote agent authentication` * define a custom `security token` This will allow remote agents that are configured with the same security token to automatically join the cluster. First, create a secret to store a custom security token with which remote agent(s) should authenticate to the Bamboo server. !!!info "Security token format" 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: ``` xxd -l 20 -p /dev/urandom ``` Add the generated string (security token) to a K8s secret ``` shell kubectl create secret generic security-token --from-literal=security-token= ``` Update the Bamboo `values.yaml` with this secret and disable agent authentication: ```yaml bamboo: securityToken: secretName: "security-token" secretKey: security-token disableAgentAuth: true ``` !!!warning "Disabling remote agent authentication" 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) #### Manually * When logged into the Bamboo server instance, and from the `Agents` settings tab, **enable** `security token verification`, and **disable** `remote agent authentication` ![security_token_verification](../../assets/images/bamboo_agents/enable-disable.png){ width="900" } * Navigate to the remote agent's installation page by selecting the `Install remote agent` button from the `Agents` settings tab ![install_remote_agent](../../assets/images/bamboo_agents/install-remote-agent.png){ width="900" } * Create a K8s secret using the `security token` rendered on the `Installing a remote agent` page ![security_token](../../assets/images/bamboo_agents/security-token.png){ width="900" } create secret using token... ``` shell kubectl create secret generic security-token --from-literal=security-token= ``` ### 2. Deploy agent * Update the bamboo agent `values.yaml` to utilize the security token secret and point to the bamboo server instance ```yaml replicaCount: 3 agent: securityToken: secretName: "security-token" secretKey: security-token server: "bamboo.bamboo.svc.cluster.local" ``` !!!info "Values" * As long as your cluster has the physical resources the `replicaCount` can be set to any value from `1` .. `1 + 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` * Install the agent ```shell helm install bamboo-agent atlassian-data-center/bamboo-agent -f values.yaml ``` !!!tip "Custom agents" 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: * JDK 11 * Git & Git LFS * Maven 3 * Python 3 For details on defining and deploying agents with custom/additional capabilities view the [agent capabilities guide](AGENT_CAPABILITIES.md) ## Scaling the agent count The number of active agents can be easily increased or decreased: ``` shell helm upgrade --set replicaCount= \ --reuse-values \ atlassian-data-center/bamboo-agent ``` ## Troubleshooting You 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}. ================================================ FILE: docs/docs/examples/bitbucket/.pages ================================================ nav: - OpenSearch : BITBUCKET_OPENSEARCH.md - Elasticsearch (Deprecated) : BITBUCKET_ELASTICSEARCH.md - Smart Mirrors : BITBUCKET_MIRRORS.md - SSH : BITBUCKET_SSH.md - Mesh : BITBUCKET_MESH.md - ... ================================================ FILE: docs/docs/examples/bitbucket/BITBUCKET_AWS_OPENSEARCH.md ================================================ # Configure AWS OpenSearch with Bitbucket ## Configuration Example ```yaml bitbucket: # Disable default OpenSearch deployment opensearch: enabled: false # Configure AWS OpenSearch connection additionalEnvironmentVariables: - name: SEARCH_ENABLED value: "true" - name: PLUGIN_SEARCH_CONFIG_BASEURL value: "https://your-opensearch-endpoint.region.es.amazonaws.com" - name: PLUGIN_SEARCH_CONFIG_USERNAME valueFrom: secretKeyRef: name: aws-opensearch-credentials key: username - name: PLUGIN_SEARCH_CONFIG_PASSWORD valueFrom: secretKeyRef: name: aws-opensearch-credentials key: password ``` ## Create AWS OpenSearch Credentials Secret ```shell kubectl create secret generic aws-opensearch-credentials \ --from-literal=username=your-username \ --from-literal=password=your-password \ -n your-namespace ``` ================================================ FILE: docs/docs/examples/bitbucket/BITBUCKET_ELASTICSEARCH.md ================================================ !!!warning "Elasticsearch deprecation notice" Elasticsearch has been deprecated as a search platform for Bitbucket. Use [OpenSearch](../BITBUCKET_OPENSEARCH) instead. # Bitbucket Elasticsearch recommendations While 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. ## Installing and configuring Elasticsearch in your Kubernetes cluster ### Installing Elasticsearch into your Kubernetes cluster Choose 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. There 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: ```bash helm repo add elastic https://helm.elastic.co ``` then install it: ```bash helm install elasticsearch --namespace --set imageTag="7.9.3" elastic/elasticsearch ``` !!! info "Prerequisites of Elasticsearch Helm chart" Running the above commands will install Elasticsearch with the default configuration, which is 3 worker nodes. However, it may not always work out of the box if failed to fulfill prerequisites for the default installation. Some example prerequisites include: * CPU/memory requests: 1000m/2Gi (for each worker node) * Preconfigured storage volumes (30Gi for each worker node) For more details refer to [Elasticsearch values.yaml file](https://github.com/elastic/helm-charts/blob/7.9/elasticsearch/values.yaml){.external}. ### Configuring your Bitbucket deployment To enable the installed Elasticsearch service you need to configure the service URL under `bitbucket:` stanza in the `values.yaml` file. Check 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}. ```yaml bitbucket: elasticSearch: baseUrl: http://elasticsearch-master..svc.cluster.local:9200 ``` This will also have the effect of disabling Bitbucket’s internal Elasticsearch instance. !!! info "Elasticsearch security" 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: ```yaml bitbucket: elasticSearch: credentials: secretName: usernameSecretKey: username passwordSecretKey: password ``` Read about [Kubernetes secrets](https://kubernetes.io/docs/concepts/configuration/secret/){.external}. ## Configuring Amazon Elasticsearch Service with Bitbucket on Kubernetes ### Creating an Amazon Elasticsearch Service domain with a master user The 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: 1. In the EKS console navigate to **Your Cluster → Networking** and note the VPC ID. 2. In the Elasticsearch console create a new domain: 1. Select a production deployment. 2. Select Elasticsearch version 7.9. 3. In the next screen configure the AZs and nodes as appropriate for your expected workload. 4. On the **Access and security** page: 1. Select the same VPC as the EKS cluster, as noted in step 1. 2. Select appropriate subnets for each AZ; private subnets are fine. 3. Select appropriate security groups that will grant node/pod access. 4. Tick **Fine–grained access control**: * Select **Create master user** and add a username and a strong password. 5. Configure tags, etc. as appropriate for your organisation. Once the Elasticsearch domain has finished creating, make a note of the **VPC Endpoint**, which will be an HTTPS URL. ### Configuring your Bitbucket deployment To 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: ```yaml bitbucket: elasticSearch: baseUrl: credentials: secretName: usernameSecretKey: username passwordSecretKey: password ``` !!! info "" Read about [Kubernetes secrets](https://kubernetes.io/docs/concepts/configuration/secret/){.external}. ## Testing your Elasticsearch connection To 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. ![bitbucket-elasticsearch](../../assets/images/bitbucket-elasticsearch.png) ================================================ FILE: docs/docs/examples/bitbucket/BITBUCKET_MESH.md ================================================ # Bitbucket Mesh Bitbucket Mesh is a distributed, replicated, and horizontally scalable Git repository storage system, which increases performance and improves the resilience of Bitbucket. ![bitbucket_mesh](../../assets/images/bitbucket_with_mesh.png) You can learn more details about Bitbucket Mesh on the [official documentation page](https://confluence.atlassian.com/bitbucketserver/bitbucket-mesh-1128304351.html){.external}. !!!tip "Recommendations for Mesh deployments" **Bitbucket version** By default, the Helm charts target the latest Bitbucket LTS version. However, Mesh is only supported from version 8.0. You will need to select an 8.x version of Bitbucket to deploy Mesh. Learn more details below. **Mesh agent version** Bitbucket Mesh agents are versioned independently from Bitbucket. You should select the appropriate version for the deployed version of Bitbucket. See the [Mesh download page](https://www.atlassian.com/software/bitbucket/download-mesh-archives){.external} for available versions. **Number of Mesh nodes** In order for high-availability to be possible, we recommend having a minimum of three Mesh nodes. There is no maximum on the number of nodes. **Mesh node co-location** We don't currently support deploying Mesh nodes into multiple availability zones. Just like the shared file system based deployments, the Mesh nodes (that is, the repository storage) and the application nodes must be co-located. **Other Mesh deployment requirements** For more details on the requirements and limitations of Mesh deployments, check the [the Bitbucket Mesh FAQ](https://confluence.atlassian.com/enterprise/bitbucket-data-center-faq-776663707.html#BitbucketDataCenterFAQ-Mesh){.external}. ### Configuring your Bitbucket and Mesh deployment For backwards compatibility, the Helm charts default to Mesh being disabled. To enable it, you will need to configure the service under `bitbucket:` stanza in the `values.yaml` file, substituting the values below from the above steps where appropriate: ```yaml image: tag: bitbucket: mesh: enabled: true image: version: ``` ### Adding the Mesh nodes to Bitbucket To enable the deployed Mesh nodes you need to add them to the Bitbucket Data Center instance in the administration area. To do so, you'll need the service URL of each node; these are usually of the form `bitbucket-mesh-`. Check the Kubernetes official documentation to learn how to get a [DNS record for a service](https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/#services){.external}. To connect the Mesh node: 1. In your Bitbucket Data Center instance, navigate to **Administration** > **Git** > **Bitbucket Mesh**. 1. Enter the URL of the Mesh node in the Node URL field (e.g. `http://bitbucket-mesh-1:7777`). 1. (Optional) Enter a name for the Mesh node in the Node name field. 1. Select **Add Mesh node**. [Learn more details about Mesh configuration](https://confluence.atlassian.com/bitbucketserver/set-up-and-configure-mesh-nodes-1128304356.html#SetupandconfigureMeshnodes-ConnectingtheMeshnodetoBitbucket). ### Migrating existing repositories to Mesh [Learn how to migrate repositories to Mesh](https://confluence.atlassian.com/bitbucketserver/migrate-repositories-to-bitbucket-mesh-1128304358.html). ================================================ FILE: docs/docs/examples/bitbucket/BITBUCKET_MIRRORS.md ================================================ # Smart Mirroring Smart 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. ![smart mirrors](../../assets/images/bitbucket_mirrors/smart_mirrors_diagram.png) You can learn more details about smart mirroring on the [official documentation page](https://confluence.atlassian.com/bitbucketserver/smart-mirroring-776640046.html). !!!tip "Upstream/Primary instance" **Primary instance** is sometimes called **upstream** instance. ## Requirements !!!warning "Primary instance prerequisites" **Your primary Bitbucket instance must be a fully licensed Bitbucket Data Center instance** 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. **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** 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. **The primary Bitbucket instance must have SSH enabled** 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. ## Installation ### Overview 1. Install the **primary** as usual with Bitbucket Helm chart. * You need to make sure the instance complies with all the above listed requirements. 2. Install the **mirror** with second Bitbucket Helm chart. * There is a set of properties that need to be configured to make the mirror work. 3. Approve the **mirror** in the **primary** instance. ### Steps #### Mirror Farm installation in Kubernetes !!!info Ingress configuration 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. 1. Install the **primary** as usual with Bitbucket Helm chart. * You need to make sure the instance complies with all the above listed requirements. * Verify that you are able to clone from the primary via SSH protocol. * Verify that primary instance is accessible over HTTPS with a valid SSL certificate. 2. Create a new file `values-mirror.yaml` with the following content: ``` yaml bitbucket: mode: mirror displayName: Bitbucket Mirror clustering: enabled: true applicationMode: "mirror" mirror: upstreamUrl: # for example https://bitbucket-upstream.example.com # nginx specific configuration ingress: create: true host: bitbucket-mirror.example.com annotations: cert-manager.io/issuer: "letsencrypt-prod" # Default issuer tlsSecretName: # E.g. tls-certificate-mirror # enables persistence for mirror data volumes: localHome: persistentVolumeClaim: create: true ``` 3. Edit the file to change the placeholder values. * `bitbucket.mirror.upstreamUrl` * `ingress.host` * `ingress.tlsSecretName` 4. Install the mirror ``` shell helm install bitbucket-mirror atlassian-data-center/bitbucket -f values-mirror.yaml ``` #### Mirror farm authorization These 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). 1. Visit the mirror URL (it might take a couple of minutes to come up) 2. Click on *Go to the primary server* in the mirror UI. The link will take you to the administration section of the primary instance.
![mirror_setup](../../assets/images/bitbucket_mirrors/mirror_authorize.png){ width="400" } 3. Click *Authorize* next to the mirror
![click_authorize](../../assets/images/bitbucket_mirrors/upstream_authorize.png) 4. Select which projects should be synchronized
![select_projects](../../assets/images/bitbucket_mirrors/select_projects_to_mirror.png) 5. Wait for the projects to be synchronized
![project_synchronized](../../assets/images/bitbucket_mirrors/mirror_synchronized.png) 6. Verify that the synchronized projects can be cloned from the mirror
![clone_from_mirror](../../assets/images/bitbucket_mirrors/clone_from_mirror.png){ width="400"} ## Scaling the mirror farm As 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: ``` shell helm upgrade --set replicaCount= \ --reuse-values \ atlassian-data-center/bitbucket ``` ## Adding or removing additional mirror farms It is possible to connect multiple mirror farms to a single primary instance. This can be useful to improve local performance for geographically distributed teams. *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. *To remove a mirror farm*: 1. Navigate to *Mirrors* administration section on the **primary** 2. Select the mirror from the list 3. Click *Delete* button 4. Uninstall the deleted mirror helm release from the cluster ## Troubleshooting You 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). ================================================ FILE: docs/docs/examples/bitbucket/BITBUCKET_OPENSEARCH.md ================================================ !!!info "Helm chart version" OpenSearch sub-chart is supported in Bitbucket Helm chart version 1.20 onwards. ## Deploy OpenSearch Helm chart with Bitbucket !!!warning "Support disclaimer" 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}. 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. To deploy OpenSearch Helm chart and automatically configure Bitbucket to use it as a search platform, set the following in your Helm values file: ```yaml opensearch: install: true ``` This will: * auto-generate the initial OpenSearch admin password and create a Kubernetes secret with `OPENSEARCH_INITIAL_ADMIN_PASSWORD` key * 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 * set `PLUGIN_SEARCH_CONFIG_BASEURL` to `http://opensearch-cluster-master:9200` unless overridden in `opensearch.baseUrl` * set `PLUGIN_SEARCH_CONFIG_USERNAME` to `admin` (this is the initial admin user created when the OpenSearch cluster starts for the very first time) * set `PLUGIN_SEARCH_CONFIG_PASSWORD` to a randomly generated password saved to `opensearch-initial-password` secret ## Create dedicated OpenSearch user When 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. ### Hash passwords Passwords in `internal_users.yml` must be hashed. You can use `hash.sh` script bundled with Bitbucket to hash your passwords, for example: ```shell docker 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" $2y$12$bcUjaXcfutyYwkjp6r/RdePrywC3BmQLKvN77XuuR0PJs0qjBooSv ``` If Bitbucket is already up and running in your Kubernetes cluster, you can run exec into the Bitbucket container to hash a password: ```shell kubectl 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" $2y$12$x910YF09tcfhNs009vOzWOMy9fswhpsuV5/AiiPwbY4rp5BXKv2tv ``` ### Create internal_users.yml file This 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. ```yaml _meta: type: "internalusers" config_version: 2 admin: hash: "$2y$12$bcUjaXcfutyYwkjp6r/RdePrywC3BmQLKvN77XuuR0PJs0qjBooSi" reserved: true backend_roles: - "admin" description: "Demo admin user" bitbucket: hash: "$2y$12$x910YF09tcfhNs009vOzWOMy9fswhpsuV5/AiiPwbY4rp5BXKv2tu" reserved: true backend_roles: - "admin" description: "Bitbucket admin user" ``` ### Create Kubernetes secret Create a Kubernetes secret with 3 keys in its data: !!!warning "internal_users.yml" 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. ```shell kubectl create secret generic opensearch-internal-users \ --from-literal=username=bitbucket \ --from-literal=password="mySecureBitbucketPassword123" \ --from-file=internal_users.yml=/path/to/internal_users.yml \ -n atlassian ``` ### Update Helm values Now that the secret has been created, update your Helm values to point OpenSearch and Bitbucket to `opensearch-internal-users` secret: ```yaml opensearch: install: true credentials: secretName: opensearch-internal-users usernameSecretKey: username passwordSecretKey: password securityConfig: internalUsersSecret: opensearch-internal-users ``` If 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. ## Override OpenSearch Helm chart values You 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: ```yaml opensearch: singleNode: false replicas: 5 config: opensearch.yml: | cluster.name: custom-cluster ``` ## Enable SSL with Custom Certificates By 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. To enable SSL in OpenSearch and start the service on a secure port, you need to: * Enable SSL HTTPS in Helm values. * Create Kubernetes secrets with `ca`, `certificate` and `key`, and pass them to OpenSearch. * Add `ca.crt` to Java trust store in Bitbucket containers if the custom certificate is not signed by a public authority. Below 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: ```shell openssl 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 openssl 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 openssl x509 -req -days 365 -in opensearch-cluster-master.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out opensearch-cluster-master.crt ``` It is important to generate the certificate for `opensearch-cluster-master` CN because this is the actual OpenSearch service/host name in the target namespace. Once done, create 3 Kubernetes secrets: ```shell kubectl create secret generic opensearch-ssl-ca -n atlassian --from-file=root-ca.pem=ca.crt kubectl create secret generic opensearch-ssl-key -n atlassian --from-file=esnode-key.pem=opensearch-cluster-master.key kubectl create secret generic opensearch-ssl-cert -n atlassian --from-file=esnode.pem=opensearch-cluster-master.crt ``` Enable ssl http plugin, override the default ca, certificate and key, as well as provide additional volume mounts in Bitbucket Helm values file: ```yaml opensearch: extraEnvs: - name: plugins.security.ssl.http.enabled value: "true" - name: plugins.security.ssl.transport.pemkey_filepath value: "esnode-key.pem" - name: plugins.security.ssl.transport.pemcert_filepath value: "esnode.pem" - name: plugins.security.ssl.transport.pemtrustedcas_filepath value: "root-ca.pem" secretMounts: - name: opensearch-ssl-cert secretName: opensearch-ssl-cert path: /usr/share/opensearch/config/esnode.pem subPath: esnode.pem - name: opensearch-ssl-key secretName: opensearch-ssl-key path: /usr/share/opensearch/config/esnode-key.pem subPath: esnode-key.pem - name: opensearch-ssl-ca secretName: opensearch-ssl-ca path: /usr/share/opensearch/config/root-ca.pem subPath: root-ca.pem ``` When 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: ```yaml bitbucket: additionalCertificates: secretName: opensearch-ssl-ca ``` Additionally, you need to update the protocol specified in the baseUrl to HTTPS: ```yaml bitbucket: additionalCertificates: secretName: opensearch-ssl-ca opensearch: baseUrl: https://opensearch-cluster-master:9200 ``` ## Enable Ingress To 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: ```yaml opensearch: baseUrl: https://myopensearch.com ingress: install: true ``` Important considerations: * Ensure that the `baseUrl` is set to use HTTPS protocol, which encrypts the data exchanged with the OpenSearch cluster * Ensure that the Ingress hostname can be resolved from within the Kubernetes cluster network * 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` ## Use AWS OpenSearch Service If 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. ### Prerequisites * Create an AWS OpenSearch Service domain * Configure domain access policy to allow your EKS cluster * Have the domain endpoint URL and credentials ready ### Configuration ```yaml bitbucket: clustering: enabled: true # Do not enable the opensearch helm chart opensearch: enabled: false additionalEnvironmentVariables: - name: SEARCH_ENABLED value: "false" - name: PLUGIN_SEARCH_CONFIG_BASEURL value: "https://search-your-domain-abc123.us-east-1.es.amazonaws.com" - name: PLUGIN_SEARCH_CONFIG_USERNAME valueFrom: secretKeyRef: name: aws-opensearch-credentials key: username - name: PLUGIN_SEARCH_CONFIG_PASSWORD valueFrom: secretKeyRef: name: aws-opensearch-credentials key: password ``` ### Create AWS OpenSearch Credentials Secret ```shell kubectl create secret generic aws-opensearch-credentials \ --from-literal=username=your-master-username \ --from-literal=password=your-master-password \ -n your-namespace ``` ### Using IAM Authentication For domains using IAM authentication, configure IAM roles and omit username/password: ```yaml bitbucket: clustering: enabled: true opensearch: enabled: false additionalEnvironmentVariables: - name: SEARCH_ENABLED value: "false" - name: PLUGIN_SEARCH_CONFIG_BASEURL value: "https://search-your-domain-abc123.us-east-1.es.amazonaws.com" # No username/password needed - uses IAM role ``` ## Troubleshooting ### Authentication If you run into auth issues (401 response from OpenSearch), check the following: * exec into the Bitbucket container and run: ```shell curl -v -u ${PLUGIN_SEARCH_CONFIG_USERNAME}:${PLUGIN_SEARCH_CONFIG_PASSWORD} http://opensearch-cluster-master:9200/_cat/indices?v ``` 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` * you can find out where the actual values of `PLUGIN_SEARCH_CONFIG_USERNAME` and `PLUGIN_SEARCH_CONFIG_PASSWORD` environment variables come from by running: ```shell kubectl get pod bitbucket-0 -n atlassian -o jsonpath="{.spec.containers[0].env[?(@.name=='PLUGIN_SEARCH_CONFIG_USERNAME')]}" kubectl get pod bitbucket-0 -n atlassian -o jsonpath="{.spec.containers[0].env[?(@.name=='PLUGIN_SEARCH_CONFIG_PASSWORD')]}" ``` * 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. ### Networking The 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. If you see connection refused/timeout errors, make sure all OpenSearch pods are in a Ready state and the corresponding endpoints have been created: ```shell kubectl describe pod -n atlassian -l=app.kubernetes.io/component=opensearch-cluster-master ``` ```shell kubectl get endpoints -n atlassian NAME ENDPOINTS AGE bitbucket 10.0.2.31:7999,10.0.2.31:7990,10.0.2.31:5701 113m opensearch-cluster-master 10.0.1.170:9200,10.0.1.170:9300 113m opensearch-cluster-master-headless 10.0.1.170:9600,10.0.1.170:9200,10.0.1.170:9300 113m ``` ================================================ FILE: docs/docs/examples/bitbucket/BITBUCKET_SESSION_AFFINITY.md ================================================ # Configure Session Stickiness with NGINX Ingress ## Default Configuration ```yaml ingress: create: true nginx: true # Enables session stickiness automatically host: bitbucket.example.com bitbucket: clustering: enabled: true ``` ## Custom Configuration ```yaml ingress: create: true nginx: true host: bitbucket.example.com annotations: "nginx.ingress.kubernetes.io/session-cookie-name": "BITBUCKET-SESSION" "nginx.ingress.kubernetes.io/session-cookie-max-age": "28800" # 8 hours ``` ## Verifying Session Stickiness Test that session stickiness is working: ```shell # Check ingress annotations kubectl describe ingress bitbucket -n atlassian # Test with curl (look for Set-Cookie header) curl -I https://bitbucket.example.com/status ``` ## Troubleshooting If users are experiencing random logouts or Git operation failures: 1. **Verify NGINX annotations are applied**: ```shell kubectl get ingress bitbucket -n atlassian -o yaml ``` 2. **Check if requests hit the same pod**: ```shell kubectl logs -f -l app.kubernetes.io/name=bitbucket -n atlassian ``` 3. **Ensure clustering is enabled**: ```yaml bitbucket: clustering: enabled: true ``` !!!tip "Production recommendation" Set `session-cookie-max-age` to match your typical user session duration (e.g., 8 hours = 28800 seconds) to balance user experience with security. ================================================ FILE: docs/docs/examples/bitbucket/BITBUCKET_SSH.md ================================================ # SSH service in Bitbucket on Kubernetes In 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. Depending on the need of your deployment, SSH access can be provided through three mechanisms: 1. 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. 2. 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. 3. Exposing Bitbucket service as `LoadBalancer` and setting the desired ssh port (defaults to `7999`) ## NGINX Ingress controller config for SSH connections We 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}. !!!info "Namespace co-location" These instructions should be performed in the same namespace in which the Ingress controller resides. ### 1. Create ConfigMap Create a new `ConfigMap`: ``` shell kubectl create configmap tcp-services ``` In our example we deployed Bitbucket using the Helm release name `bitbucket` in the namespace `ssh-test`, update the `ConfigMap` `tcp-services` accordingly: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: tcp-services namespace: ingress-nginx data: 7999: "/:ssh" ``` ### 2. Update Ingress deployment Next, we have to edit the `deployment` of the ingress controller and add the `--tcp-services-configmap` option: ```shell kubectl edit deployment ``` Add this line in the `args` of the container `spec`: ```shell - --tcp-services-configmap=$(POD_NAMESPACE)/tcp-services ``` so it looks something like this: ```yaml spec: containers: - args: - /nginx-ingress-controller - --publish-service=$(POD_NAMESPACE)/ingress-nginx-controller - --election-id=ingress-controller-leader - --ingress-class=nginx - --configmap=$(POD_NAMESPACE)/ingress-nginx-controller - --validating-webhook=:8443 - --validating-webhook-certificate=/usr/local/certificates/cert - --validating-webhook-key=/usr/local/certificates/key - --tcp-services-configmap=$(POD_NAMESPACE)/tcp-services ``` ### 3. Update the Ingress service Update the Ingress service to include an additional `port` definition for `ssh` ```shell kubectl edit service ``` Add this section in the `ports` of the container `spec`: ```yaml - name: ssh port: 7999 protocol: TCP ``` so it looks something like this: ```yaml spec: clusterIP: 10.100.19.60 externalTrafficPolicy: Cluster ports: - name: http nodePort: 31381 port: 80 protocol: TCP targetPort: http - name: https nodePort: 32612 port: 443 protocol: TCP targetPort: https - name: ssh port: 7999 protocol: TCP ``` After the deployment has been upgraded, the `SSH` service should be available on port `7999`. ## LoadBalancer service for SSH connections on AWS In the values file for the helm chart, the extra SSH service can be enabled like this: ```yaml bitbucket: sshService: enabled: true ``` On 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: ```yaml bitbucket: sshService: enabled: true annotations: external-dns.alpha.kubernetes.io/hostname: bitbucket-ssh.example.com additionalEnvironmentVariables: - name: PLUGIN_SSH_BASEURL value: ssh://bitbucket-ssh.example.com/ ``` ## Expose Bitbucket Service as a LoadBalancer This 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}: ```yaml bitbucket: service: port: 443 sshPort: 22 type: LoadBalancer annotations: external-dns.alpha.kubernetes.io/hostname: bitbucket.example.com service.beta.kubernetes.io/aws-load-balancer-ssl-ports: "443" service.beta.kubernetes.io/aws-load-balancer-ssl-cert: arn:aws:acm:us-east-1:111111111111:certificate/8xy4ny81-0a4w-8caq-a524-1101cv3v4vwb additionalEnvironmentVariables: - name: PLUGIN_SSH_BASEURL value: ssh://bitbucket.example.com ingress: host: bitbucket.example.com ``` The 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. The 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`. !!!info "Ingress host" Even though `ingress` is disabled, `ingress.host` needs to be set because it is used in a few conditions in the StatefulSet template. ================================================ FILE: docs/docs/examples/cluster/AKS_SETUP.md ================================================ # Preparing an AKS cluster This example provides instructions for creating a Kubernetes cluster using [Azure AKS](https://azure.microsoft.com/en-au/services/kubernetes-service/){.external}. ## Prerequisites We 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. ## Manual creation Follow the [Azure Kubernetes Service Quickstart](https://docs.microsoft.com/en-au/azure/aks/kubernetes-walkthrough){.external} for details on creating an AKS cluster. --- !!!tip "Next step - Ingress controller" Having established a cluster, continue with provisioning the next piece of prerequisite infrastructure, the [Ingress controller](../../userguide/PREREQUISITES.md#provision-an-ingress-controller). ================================================ FILE: docs/docs/examples/cluster/CLOUD_PROVIDERS.md ================================================ # Provisioning Kubernetes clusters on cloud-based providers Here are installation and configuration instructions for cloud providers: * [Amazon EKS](EKS_SETUP.md) * [Google GKE](GKE_SETUP.md) * [Azure AKS](AKS_SETUP.md) ================================================ FILE: docs/docs/examples/cluster/EKS_SETUP.md ================================================ # Preparing an EKS cluster This example provides instructions for creating a Kubernetes cluster using [Amazon EKS](https://aws.amazon.com/eks/){.external}. ## Prerequisites We recommend installing and configuring [eksctl](https://docs.aws.amazon.com/eks/latest/userguide/eksctl.html){.external}, allowing for CLI interaction with the EKS cluster. ## Manual creation Follow 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: ```yaml apiVersion: eksctl.io/v1alpha5 kind: ClusterConfig metadata: name: atlassian-cluster region: ap-southeast-2 managedNodeGroups: - name: appNodes instanceType: m5.large desiredCapacity: 2 ssh: # enable SSH using SSM enableSsm: true ``` ???question "Cluster considerations" It's always a good idea to consider the following points before creating the cluster: 1. [Geographical region](https://aws.amazon.com/about-aws/global-infrastructure/regions_az/){.external} - where will the cluster reside. 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. 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). Adding the config above to a file named `config.yaml` provision the cluster: ```shell eksctl create cluster -f config.yaml ``` --- !!!tip "Next step - Ingress controller" Having established a cluster, continue with provisioning the next piece of prerequisite infrastructure, the [Ingress controller](../../userguide/PREREQUISITES.md#provision-an-ingress-controller). ================================================ FILE: docs/docs/examples/cluster/GKE_SETUP.md ================================================ # Preparing an GKE cluster This example provides instructions for creating a Kubernetes cluster using [Google GKE](https://cloud.google.com/kubernetes-engine){.external}. ## Prerequisites We recommend installing and configuring [Google Cloud SDK](https://cloud.google.com/sdk/docs/install){.external}, allowing for CLI interaction with an GKE cluster. ## Manual creation Follow the [How-to guides](https://cloud.google.com/kubernetes-engine/docs/how-to#creating-clusters){.external} for details on creating an GKE cluster. --- !!!tip "Next step - Ingress controller" Having established a cluster, continue with provisioning the next piece of prerequisite infrastructure, the [Ingress controller](../../userguide/PREREQUISITES.md#provision-an-ingress-controller). ================================================ FILE: docs/docs/examples/confluence/.pages ================================================ collapse_single_pages: false nav: - CONFLUENCE_OPENSEARCH.md - ... ================================================ FILE: docs/docs/examples/confluence/CONFLUENCE_OPENSEARCH.md ================================================ # Configuring OpenSearch for Confluence !!!info "Confluence and Helm chart version" OpenSearch is supported in Confluence 8.9.0 and Helm chart 1.19 onwards. As 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. Find more information on advantages of using OpenSearch in the [official documentation](https://confluence.atlassian.com/doc/configuring-opensearch-for-confluence-1387594125.html){.external} ## Deploy OpenSearch Helm Chart with Confluence !!!warning "Support disclaimer" 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}. 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. ## Deploy with the default settings To deploy OpenSearch Helm chart and automatically configure Confluence to use it as a search platform, set the following in your Helm values file: ```yaml opensearch: enabled: true ``` This will: * auto-generate the initial OpenSearch admin password and create a Kubernetes secret with `OPENSEARCH_INITIAL_ADMIN_PASSWORD` key * 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 * 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} ## Override OpenSearch Helm chart values You 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: ```yaml opensearch: singleNode: false replicas: 5 config: opensearch.yml: | cluster.name: opensearch-cluster ``` ================================================ FILE: docs/docs/examples/database/AMAZON_RDS.md ================================================ # Creating an RDS database instance This example provides instructions for creating an Amazon [RDS DB instance](https://aws.amazon.com/rds/){.external}. ## Prerequisites * 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. ## Database creation There are two steps for creating the database: 1. [Initialize database server](#1-initialize-database-server) 2. [Initialize database and user](#2-initialize-database-and-user) ### 1. Initialize database server For 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}. ### 2. Initialize database and user !!!danger "Don't forget to create the database and user!" This is a required step. For details on creating the application database and database user follow the appropriate guide below: === "Jira" [Create database for Jira](https://confluence.atlassian.com/adminjiraserver/connecting-jira-applications-to-a-database-938846850.html){.external} === "Confluence" [Create database for Confluence](https://confluence.atlassian.com/doc/database-configuration-159764.html#DatabaseConfiguration-Databasesetupsetup){.external} === "Bitbucket" [Create database for Bitbucket](https://confluence.atlassian.com/bitbucketserver/connect-bitbucket-to-an-external-database-776640378.html){.external} === "Bamboo" [Create database for Bamboo](https://confluence.atlassian.com/bamboo/connecting-bamboo-to-an-external-database-289276815.html){.external} === "Crowd" [Create database for Crowd](https://confluence.atlassian.com/crowd/connecting-crowd-to-a-database-4030904.html){.external} --- !!!tip "Next step - Shared storage" Having created the database continue with provisioning the next piece of prerequisite infrastructure, [shared storage](../../userguide/PREREQUISITES.md#configure-a-shared-home-volume). ================================================ FILE: docs/docs/examples/database/CLOUD_PROVIDERS.md ================================================ # Provisioning databases on cloud-based providers !!!info "Supported databases" Your selected database engine type must be supported by the Data Center product you wish to install: === "Jira" [Jira supported databases](https://confluence.atlassian.com/adminjiraserver/supported-platforms-938846830.html#Supportedplatforms-Databases){.external} === "Confluence" [Confluence supported databases](https://confluence.atlassian.com/doc/supported-platforms-207488198.html#SupportedPlatforms-Databases){.external} === "Bitbucket" [Bitbucket supported databases](https://confluence.atlassian.com/bitbucketserver/supported-platforms-776640981.html#Supportedplatforms-databasesDatabases){.external} === "Bamboo" [Supported databases](https://confluence.atlassian.com/bamboo/supported-platforms-289276764.html#Supportedplatforms-Databases){.external} === "Crowd" [Crowd supported databases](https://confluence.atlassian.com/crowd/supported-platforms-191851.html#SupportedPlatforms-Databases){.external} Database deployment and configuration instructions for cloud providers can be found below: * [Amazon RDS](AMAZON_RDS.md) ================================================ FILE: docs/docs/examples/external_libraries/EXTERNAL_LIBS.md ================================================ # External libraries and plugins !!!warning "`.jar` files only" 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` In some situations, you may want to load 3rd party plugins, drivers or libraries so that they are available to the product being installed. An example of when this may be needed are for those products that do not ship with the appropriate `MySQL` and `Oracle` `JDBC` drivers. There are 3 strategies for doing this, you can either: * [use the required prerequisite shared home volume](#shared-home-volume) * [create a custom volume specifically for this purpose](#custom-volume) * [provide a custom command for the `nfsPermissionFixer`](#custom-command) Each approach will be discussed below. !!!info "Approach" 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 keep things clean you may decide to mount these 3rd party libraries in a volume of their own. This approach would be particularly useful when these libraries need to be shared with other Pod's in your cluster. ## Shared home volume This approach consists of 3 high-level tasks: 1. Create sub-dir in `shared-home` volume 2. Copy libraries to sub-dir 3. Update `additionalLibraries` stanza in `values.yaml` ### 1. Create sub-dir Add the Pod definition below to a file called `shared-home-browser.yaml` ```yaml apiVersion: v1 kind: Pod metadata: name: shared-home-browser spec: containers: - name: browser image: debian:stable-slim volumeMounts: - mountPath: /shared-home name: shared-home command: [ "bash", "-c", "--" ] args: [ "while true; do sleep 30; done;" ] volumes: - name: shared-home persistentVolumeClaim: claimName: ``` Initialise the Pod in the same namespace in which the `shared-home` PVC was created ```bash kubectl apply -f shared-home-browser.yaml ``` Once running execute the following command, it will create the sub-sir, `libraries`, under `/shared-home` ```bash kubectl exec -it shared-home-browser -- bash -c "mkdir -p /shared-home/libraries" ``` ### 2. Copy libraries to sub-dir Now copy the files you require to the sub-dir by using the `kubectl cp` command ```bash kubectl cp my_library.jar shared-home-browser:/shared-home/libraries ``` ### 3. Update `values.yaml` Update the stanza, `additionalLibraries`, in `values.yaml` accordingly: ```yaml jira: additionalLibraries: - volumeName: shared-home subDirectory: libraries fileName: my_library.jar ``` With 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). ## Custom volume This 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`. 1. Create a new volume for storing 3rd party libraries 2. Create sub-dir for the new volume 3. Copy libraries to sub-dir 4. Update `additionalLibraries` stanza in `values.yaml` 5. Update `additionalVolumeMounts` stanza in `values.yaml` 6. Update `additional` stanza in `values.yaml` !!!info "Steps" 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. ### 1. Create new volume Using 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`. !!!warning "ReadOnlyMany" Ensure that the PV and PVC are setup with `ReadOnlyMany` access ### 2. Update `values.yaml` Assuming 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: ```yaml volumes: additional: - name: third-party-libraries persistentVolumeClaim: claimName: third-party-libraries ``` Now add this as an `additionalVolumeMounts` ```yaml additionalVolumeMounts: - volumeName: third-party-libraries mountPath: /libraries ``` Finally inject the desired libraries by defining them under `additionalLibraries` ```yaml additionalLibraries: - volumeName: third-party-libraries subDirectory: database_drivers fileName: my_library.jar ``` ## Custom command This 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 it 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: ```yaml linenums="1" nfsPermissionFixer: command: | if [[ ! -f /shared-home/drivers/mysql-driver.jar ]]; then mkdir -p /shared-home/drivers apk add dpkg wget https://dev.mysql.com/get/Downloads/Connector-J/mysql-connector-java_8.0.26-1debian10_all.deb dpkg-deb -R mysql-connector-java_8.0.26-1debian10_all.deb /tmp/ cp /tmp/usr/share/java/mysql-connector-java-8.0.26.jar /shared-home/drivers/mysql-driver.jar fi chgrp 2003 /shared-home; chmod g+w /shared-home ``` !!!warning "shared-home permissions" 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` snippet above. 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) for more details on how these permissions are applied by default. Remember to also update the `additionalLibraries` stanza accordingly: ```yaml additionalLibraries: - volumeName: shared-home subDirectory: drivers fileName: mysql-driver.jar ``` ================================================ FILE: docs/docs/examples/ingress/CONTROLLERS.md ================================================ # Provisioning a traffic entry controller To expose an Atlassian DC product outside your Kubernetes cluster, you must run **one** of the following: - an **Ingress controller** (to process Kubernetes `Ingress` resources), or - a **Gateway API controller** (to process Kubernetes Gateway API resources, such as `HTTPRoute`). The Helm charts can render either: - a Kubernetes `Ingress` when `ingress.create: true`, or - a Kubernetes Gateway API `HTTPRoute` when `gateway.create: true`. These options are **mutually exclusive** (you cannot enable both `ingress.create` and `gateway.create`). !!!note "Sticky sessions are required" 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. ## Example guides - [NGINX Ingress Controller (Ingress)](INGRESS_NGINX.md) - [Gateway API controller (Gateway API)](GATEWAY_API.md) ================================================ FILE: docs/docs/examples/ingress/DNS.md ================================================ # Create DNS record via AWS CLI !!!tip "DNS record creation using Route53" 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} First, 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): ```shell kubectl get service -n ingress | grep ingress-nginx | awk '{print $4}' | head -1 ``` the output of this command should be the name of the load balancer, take note of the name i.e. ```shell b834z142d8118406795a34df35e10b17-38927090.eu-west-1.elb.amazonaws.com ``` Next, using the first part of the load balancer name, get the `HostedZoneId` for the load balancer ```shell aws elb describe-load-balancers --load-balancer-name b834z142d8118406795a34df35e10b17 --region | jq '.LoadBalancerDescriptions[] | .CanonicalHostedZoneNameID' ``` With the `HostedZoneId` and the **full** name of the load balancer create the `JSON` "change batch" file below: ```yaml { "Comment": "An alias resource record for Jira in K8s", "Changes": [ { "Action": "CREATE", "ResourceRecordSet": { "Name": , "Type": "A", "AliasTarget": { "HostedZoneId": , "DNSName": , "EvaluateTargetHealth": true } } } ] } ``` !!!tip "DNS record name" 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}. Next get the zone ID for the hosted zone: ```shell aws route53 list-hosted-zones-by-name | jq '.HostedZones[] | select(.Name == "hoolicorp.com.") | .Id' ``` Finally, using the hosted zone ID and the `JSON` change batch file created above, initialize the record: ```shell aws route53 change-resource-record-sets --hosted-zone-id --change-batch file://change-batch.json ``` This will return a response similar to the one below: ```json { "ChangeInfo": { "Id": "/change/C03268442VMV922ROD1M4", "Status": "PENDING", "SubmittedAt": "2021-08-30T01:42:23.478Z", "Comment": "An alias resource record for Jira in K8s" } } ``` You can get the current status of the record's initialization: ```shell aws route53 get-change --id /change/C03268442VMV922ROD1M4 ``` Once the `Status` has transitioned to `INSYNC` the record is ready for use... ```json { "ChangeInfo": { "Id": "/change/C03268442VMV922ROD1M4", "Status": "INSYNC", "SubmittedAt": "2021-08-30T01:42:23.478Z", "Comment": "Creating Alias resource record sets in Route 53" } } ``` ================================================ FILE: docs/docs/examples/ingress/GATEWAY_API.md ================================================ # Gateway API controller (HTTPRoute) The Atlassian DC Helm charts support exposing products via the **Kubernetes Gateway API** by rendering a `HTTPRoute` resource when `gateway.create: true`. To use this, your cluster must have: - Gateway API CRDs installed - a Gateway API controller installed (for example, Envoy Gateway, Istio, etc.) - a `Gateway` resource that allows routes from your product namespace !!!note "What the charts create" The charts create a **`HTTPRoute`** only. You must provision the **`GatewayClass`**, **`Gateway`**, and (optionally) **TLS certificates** in your cluster. ## 1. Install a Gateway API controller Follow your chosen implementation's installation instructions: - Gateway API overview: - Implementations: ## 2. Create a Gateway Create a `Gateway` that will accept `HTTPRoute` attachments from the namespace where you install the Atlassian product. The exact `gatewayClassName`, listener configuration, and TLS configuration depend on your chosen implementation. ## 3. Configure the Helm chart Disable `ingress.create` and enable `gateway.create`. Provide a **parentRef** pointing to your `Gateway` and at least one **hostname**. ```yaml ingress: create: false gateway: create: true hostnames: - confluence.example.com https: true parentRefs: - name: atlassian-gateway namespace: gateway-system # optional, defaults to release namespace sectionName: https # optional, target a specific Gateway listener ``` !!!info "TLS termination" 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. ## Gateway values reference The `gateway` stanza is split into two groups: **Product configuration** (always active when `gateway.hostnames` is set): | Value | Description | Default | |-------|-------------|---------| | `gateway.create` | Create an `HTTPRoute` resource | `false` | | `gateway.hostnames` | Hostnames to route; first entry is used as the canonical hostname for base URL and proxy settings | `[]` | | `gateway.https` | Whether users access the application over HTTPS | `true` | | `gateway.externalPort` | Port users connect on; only set for non-standard ports | `443` (https) / `80` (http) | | `gateway.path` | Base path; falls back to `.service.contextPath` when empty | (empty) | **HTTPRoute configuration** (only applies when `gateway.create: true`): | Value | Description | Default | |-------|-------------|---------| | `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) | | `gateway.pathType` | Path matching type: `PathPrefix`, `Exact`, or `RegularExpression` | `PathPrefix` | | `gateway.annotations` | Annotations to add to the HTTPRoute | `{}` | | `gateway.labels` | Labels to add to the HTTPRoute | `{}` | | `gateway.filters` | [HTTPRouteFilter](https://gateway-api.sigs.k8s.io/reference/spec/#gateway.networking.k8s.io/v1.HTTPRouteFilter){.external} list (header modification, redirects, URL rewrites) | `[]` | | `gateway.timeouts.request` | Total request timeout | `60s` | | `gateway.timeouts.backendRequest` | Backend request timeout | `60s` | | `gateway.additionalRules` | Extra [HTTPRouteRule](https://gateway-api.sigs.k8s.io/reference/spec/#gateway.networking.k8s.io/v1.HTTPRouteRule){.external} entries for advanced routing | `[]` | !!!note "Using gateway config without creating an HTTPRoute" 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. ## 4. Timeouts The `gateway.timeouts` block replaces the Ingress-style `proxyReadTimeout` / `proxySendTimeout` settings: ```yaml gateway: timeouts: request: "60s" # total request timeout backendRequest: "60s" # backend request timeout ``` !!!warning "No Gateway API equivalents" 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`). ## Configure session affinity (sticky sessions) Session affinity is **required** for Atlassian DC products and is **not** part of the standard `HTTPRoute` API. See [Session affinity with Gateway API](GATEWAY_API_SESSION_AFFINITY.md) for implementation-specific examples (cookie-based) and links for further reading. ================================================ FILE: docs/docs/examples/ingress/GATEWAY_API_SESSION_AFFINITY.md ================================================ # Session Affinity with Gateway API Atlassian 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: ```yaml nginx.ingress.kubernetes.io/affinity: "cookie" nginx.ingress.kubernetes.io/affinity-mode: "persistent" ``` With Gateway API, session affinity is **not** part of the standard `HTTPRoute` spec and must be configured separately. ## Cookie naming Use 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. ## Options at a glance | Approach | Cookie-based | Standard channel | |----------|:---:|:---:| | Implementation policy (Option 1) | Yes | N/A (separate CRD) | | Experimental `sessionPersistence` (Option 2) | Yes | No (experimental) | --- ## Implementation-specific policies (recommended) Each Gateway API implementation provides its own policy resource for session affinity. Create the appropriate resource in the **same namespace** as your Helm release. ### Envoy Gateway ```yaml apiVersion: gateway.envoyproxy.io/v1alpha1 kind: BackendTrafficPolicy metadata: name: -session-affinity namespace: spec: targetRefs: - group: gateway.networking.k8s.io kind: HTTPRoute name: - loadBalancer: type: ConsistentHash consistentHash: type: Cookie cookie: name: ATLROUTE_ ttl: 10h ``` **Explore further:** - Envoy Gateway load balancing & session persistence: - Envoy Gateway `BackendTrafficPolicy` API: - Istio consistent-hash via `DestinationRule`: --- ## Experimental `sessionPersistence` on HTTPRoute The 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. **Explore further:** - GEP-1619: - `SessionPersistence` field reference: - Experimental CRDs install (pick a release): !!!warning "Implementation support varies" Even with experimental CRDs installed, not all Gateway implementations support `sessionPersistence`. Check your implementation's conformance/support documentation. ================================================ FILE: docs/docs/examples/ingress/INGRESS_NGINX.md ================================================ # NGINX Ingress Controller - with TLS termination [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}. !!!warning "Using these instructions" 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}. These instructions are composed of 3 high-level parts: 1. Controller installation and configuration 2. Certificate manager installation and configuration 3. Ingress resource configuration ## Controller installation and configuration We 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. ### 1. Add controller repository Add the `ingress-nginx` Helm repository: ```shell helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx ``` Update the repository: ```shell helm repo update ``` ### 2. Install controller Create a new namespace for the Ingress controller: ```shell kubectl create namespace ingress ``` Install the controller using Helm: ```shell helm install ingress-nginx ingress-nginx/ingress-nginx --namespace ingress ``` !!!info "" This will take couple of minutes. Confirm your ingress controller is installed: ``` kubectl get pods --namespace ingress ``` ### 3. DNS setup Manually 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). Once 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.: ```shell kubectl get service -n ingress | grep ingress-nginx ``` the output of this command should look something like... ```shell ingress-nginx-controller LoadBalancer 10.100.22.16 b834z142d8118406795a34df35e10b17-38927090.eu-west-1.elb.amazonaws.com 80:32615/TCP,443:31787/TCP 76m ingress-nginx-controller-admission ClusterIP 10.100.5.36 443/TCP 76m ``` Take note of the `LoadBalancer` and using it as a value update the DNS record so that traffic is routed to it. !!!info "" It can take a few minutes for the DNS to resolve these changes. ## Certificate manager installation and configuration Kubernetes certificate management is handled using [cert-manager](https://cert-manager.io/){.external}. ### 1. Install cert-manager Add the cert-manager repository ```shell helm repo add jetstack https://charts.jetstack.io ``` Update repositories ```shell helm repo update ``` Install the cert-manager using Helm ```shell helm install \ cert-manager jetstack/cert-manager \ --namespace cert-manager \ --create-namespace \ --version v1.3.1 \ --set installCRDs=true ``` Confirm the cert-manager is appropriately installed: ```shell kubectl get pods --namespace cert-manager ``` ### 2. Create certificate issuer Using the `yaml` specification below create and apply the certificate `Issuer` resource: !!!info "Namespace co-location" Ensure that the certificate issuer is installed in the same namespace that the Atlassian product will be deployed to. ```yaml apiVersion: cert-manager.io/v1 kind: Issuer metadata: name: letsencrypt-prod namespace: spec: acme: # The ACME server URL server: https://acme-v02.api.letsencrypt.org/directory # Email address used for ACME registration email: # Name of a secret used to store the ACME account private key privateKeySecretRef: name: letsencrypt-prod # Enable the HTTP-01 challenge provider solvers: - http01: ingress: class: nginx ``` Install the `Issuer` resource: ```shell kubectl apply -f issuer.yaml ``` ## Ingress resource configuration Now that the Ingress controller and certificate manager are setup the Ingress resource can be configured accordingly by updating the `values.yaml`. ### 1. Ingress resource config For TLS cert auto-provisioning and TLS termination update the `ingress` stanza within the products `values.yaml`: ```yaml ingress: create: true nginx: true maxBodySize: 250m host: path: "/" annotations: cert-manager.io/issuer: "letsencrypt-prod" # Using https://letsencrypt.org/ https: true tlsSecretName: tls-certificate ``` !!!info "Configuring the `host` value" In this case the `` would correspond to the record name that was created in [3. DNS setup](#3-dns-setup) above ## Bitbucket SSH configuration !!!warning "Additional configuration" Bitbucket requires additional Ingress config to allow for `SSH` access. See [NGINX Ingress controller config for SSH connections](../bitbucket/BITBUCKET_SSH.md) for details. --- !!!tip "Next step - Database" Having created the Ingress controller continue with provisioning the next piece of prerequisite infrastructure, the [database](../../userguide/PREREQUISITES.md#provision-a-database). ================================================ FILE: docs/docs/examples/jira/.pages ================================================ collapse_single_pages: false nav: - JIRA_OPENSEARCH.md - ... ================================================ FILE: docs/docs/examples/jira/JIRA_OPENSEARCH.md ================================================ # Configuring OpenSearch for Jira !!!info "Jira and Helm chart version" OpenSearch is supported in Jira 11.2 and Helm chart 2.0.10 onwards. As 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. ## Deploy OpenSearch Helm Chart with Jira !!!warning "Support disclaimer" 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}. 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. ## Deploy with the default settings To deploy OpenSearch Helm chart and automatically configure Jira to use it as a search platform, set the following in your Helm values file: ```yaml opensearch: enabled: true ``` This will: * auto-generate the initial OpenSearch admin password and create a Kubernetes secret with `OPENSEARCH_INITIAL_ADMIN_PASSWORD` key * 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 * 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`. ## Override OpenSearch Helm chart values You 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: ```yaml opensearch: singleNode: false replicas: 5 config: opensearch.yml: | cluster.name: opensearch-cluster ``` ## Use an existing OpenSearch secret If you have a pre-created Kubernetes secret with the OpenSearch admin password, you can reference it instead of having the chart auto-generate one: ```yaml opensearch: enabled: true credentials: createSecret: false existingSecretRef: name: my-opensearch-secret ``` The secret must contain a key named `OPENSEARCH_INITIAL_ADMIN_PASSWORD`. ## Connect to an external OpenSearch instance If you already have an OpenSearch cluster running outside of Kubernetes (or managed separately), you can configure Jira to use it without deploying the bundled OpenSearch Helm chart. OpenSearch properties are written to `jira-config.properties` at container startup via the `additionalConfigProperties` mechanism (see [Additional config properties](../../userguide/CONFIGURATION.md#additional-config-properties)). First, create a Kubernetes Secret containing the OpenSearch password: ```bash kubectl create secret generic opensearch-credentials \ --from-literal=password='' ``` Then reference it in your Helm values file. The `additionalEnvironmentVariables` entry injects the secret as an environment variable, and `additionalConfigPropertiesExpandEnv` expands it into the property value at startup: ```yaml jira: additionalEnvironmentVariables: - name: MY_OPENSEARCH_PASSWORD valueFrom: secretKeyRef: name: opensearch-credentials key: password additionalConfigProperties: - "search.platform=opensearch" - "opensearch.http.url=http://opensearch-host:9200" - "opensearch.username=admin" additionalConfigPropertiesExpandEnv: - "opensearch.password={MY_OPENSEARCH_PASSWORD}" ``` For the full list of available OpenSearch properties, see [Configuring OpenSearch for Jira](https://confluence.atlassian.com/adminjiraserver/configuring-opensearch-for-jira-1620511851.html){.external}. ================================================ FILE: docs/docs/examples/logging/efk/EFK.md ================================================ # Logging in a Kubernetes environment !!!warning Disclaimer **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. ## EFK stack A common Kubernetes logging pattern is the combination of `Elasticsearch`, `Fluentd`, and `Kibana`, known as *EFK Stack*. [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. [Elasticsearch](https://www.elastic.co/){.external} is a distributed open search and analytics engine for all types of data. [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. There 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. ## Local EFK stack This 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. To 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. Follow these steps to install Elasticsearch ### 1. Install Elasticsearch Install 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 ```shell kubectl port-forward svc/elasticsearch-master 9200 ``` you can then `curl` the endpoint for the current state ```shell $ curl localhost:9200 { "name" : "elasticsearch-master-0", "cluster_name" : "elasticsearch", "cluster_uuid" : "uNdYC-2nSdWVdzPCw9P7jQ", "version" : { "number" : "7.12.0", "build_flavor" : "default", "build_type" : "docker", "build_hash" : "78722783c38caa25a70982b5b042074cde5d3b3a", "build_date" : "2021-03-18T06:17:15.410153305Z", "build_snapshot" : false, "lucene_version" : "8.8.0", "minimum_wire_compatibility_version" : "6.8.0", "minimum_index_compatibility_version" : "6.0.0-beta1" }, "tagline" : "You Know, for Search" } ``` ### 2. Enable Fluentd Now enable `Fluentd` and set the `hostname` for Elasticsearch in `values.yaml` as follows: ```yaml fluentd: enabled: true elasticsearch: hostname: elasticsearch-master ``` Fluentd 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: ### 3. Install Kibana With the same version that was used for installing [Elasticsearch](../../bitbucket/BITBUCKET_ELASTICSEARCH.md), use the `imageTag` property to install Kibana: ```shell helm install kibana --namespace --set imageTag="7.9.3" elastic/kibana ``` Make sure kibana is running by checking the deployment ```shell kubectl get deployment ``` You should see something like... ```shell NAME READY UP-TO-DATE AVAILABLE AGE helm-operator 1/1 1 1 23m ingress-nginx-release-controller 1/1 1 1 22m kibana-kibana 1/1 1 1 25m ``` Through port-forwarding you can access Kibana via `http://localhost:5601` ```shell kubectl port-forward deployment/kibana-kibana 5601 ``` 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`. ## Managed EFK stack In 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. ???+ info "Fluentbit" `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. When 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. Your 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: ```shell eksctl utils associate-iam-oidc-provider \ --cluster \ --approve ``` Then create an IAM policy to limit the permissions to connect to the Elasticsearch cluster. Before this, you need to set the following environment variables: | Environment variable | Value | |-----------------------|------------------------------------------------------------------------------------| | KUBE_NAMESPACE | The namespace for kubernetes cluster | | ES_DOMAIN_NAME | Elasticsearch domain name | | ES_VERSION | Elasticsearch version | | ES_USER | Elasticsearch username | | ES_PASSWORD | Elasticsearch password (eg. `export ES_PASSWORD="$(openssl rand -base64 8)_Ek1$"`) | | ACCOUNT_ID | AWS Account ID | | AWS_REGION | AWS region code | Now create the file `fluent-bit-policy.json` to define the policy itself: ```shell cat < ~/environment/logging/fluent-bit-policy.json { "Version": "2012-10-17", "Statement": [ { "Action": [ "es:ESHttp*" ], "Resource": "arn:aws:es:${AWS_REGION}:${ACCOUNT_ID}:domain/${ES_DOMAIN_NAME}", "Effect": "Allow" } ] } EoF ``` Next initialize the policy: ```shell aws iam create-policy \ --policy-name fluent-bit-policy \ --policy-document file://~/environment/logging/fluent-bit-policy.json ``` Create an IAM role for the service account: ```shell eksctl create iamserviceaccount \ --name fluent-bit \ --namespace dcd \ --cluster dcd-ap-southeast-2 \ --attach-policy-arn "arn:aws:iam::${ACCOUNT_ID}:policy/fluent-bit-policy" \ --approve \ --override-existing-serviceaccounts ``` Confirm that the service account with an Amazon Resource Name (ARN) of the IAM role is annotated: ```shell kubectl describe serviceaccount fluent-bit ``` Look for output similar to: ```yaml Name: fluent-bit Namespace: elastic Labels: Annotations: eks.amazonaws.com/role-arn: arn:aws:iam::000000000000:role/eksctl-your-cluster-name-addon-iamserviceac-Role1-0A0A0A0A0A0A0 Image pull secrets: Mountable secrets: fluent-bit-token-pgpss Tokens: fluent-bit-token-pgpss Events: ``` Now define the Elasticsearch domain !!!info "" This configuration will provision a public Elasticsearch cluster with Fine-Grained Access Control enabled and a built-in user database: ```shell cat < ~/environment/logging/elasticsearch_domain.json { "DomainName": ${ES_DOMAIN_NAME}, "ElasticsearchVersion": ${ES_VERSION}, "ElasticsearchClusterConfig": { "InstanceType": "r5.large.elasticsearch", "InstanceCount": 1, "DedicatedMasterEnabled": false, "ZoneAwarenessEnabled": false, "WarmEnabled": false }, "EBSOptions": { "EBSEnabled": true, "VolumeType": "gp2", "VolumeSize": 100 }, "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}/*\"}]}", "SnapshotOptions": {}, "CognitoOptions": { "Enabled": false }, "EncryptionAtRestOptions": { "Enabled": true }, "NodeToNodeEncryptionOptions": { "Enabled": true }, "DomainEndpointOptions": { "EnforceHTTPS": true, "TLSSecurityPolicy": "Policy-Min-TLS-1-0-2019-07" }, "AdvancedSecurityOptions": { "Enabled": true, "InternalUserDatabaseEnabled": true, "MasterUserOptions": { "MasterUserName": ${ES_USER}, "MasterUserPassword": ${ES_PASSWORD} } } } EOF ``` Initialize the Elasticsearch domain using the `elasticsearch_domain.json` ```shell aws es create-elasticsearch-domain \ --cli-input-json file://~/environment/logging/elasticsearch_domain.json ``` !!!info "" 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. At 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: ```shell eksctl get iamserviceaccount --cluster dcd-ap-southeast-2 ``` The output of this command should look similar to this: ```shell NAMESPACE NAME ROLE ARN kube-system cluster-autoscaler arn:aws:iam::887464544476:role/eksctl-dcd-ap-southeast-2-addon-iamserviceac-Role1-1RSRFV0BQVE3E ``` Take note of the `ROLE ARN` and export it as the environment variable `FLUENTBIT_ROLE` ```shell export FLUENTBIT_ROLE=arn:aws:iam::887464544476:role/eksctl-dcd-ap-southeast-2-addon-iamserviceac-Role1-1RSRFV0BQVE3E ``` Retrieve the Elasticsearch endpoint and update the internal database: ```shell export ES_ENDPOINT=$(aws es describe-elasticsearch-domain --domain-name ngh-search-domain --output text --query "DomainStatus.Endpoint") ``` ```shell curl -sS -u "${ES_DOMAIN_USER}:${ES_DOMAIN_PASSWORD}" \ -X PATCH \ https://${ES_ENDPOINT}/_opendistro/_security/api/rolesmapping/all_access?pretty \ -H 'Content-Type: application/json' \ -d' [ { "op": "add", "path": "/backend_roles", "value": ["'${FLUENTBIT_ROLE}'"] } ] ' ``` Finally, it is time to deploy the `Fluentbit` DaemonSet: ```shell kubectl apply -f docs/docs/examples/logging/efk/managed_es/fluentbit.yaml ``` After 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: ```shell echo "Kibana URL: https://${ES_ENDPOINT}/_plugin/kibana/" Kibana URL: https://search-domain-uehlb3kxledxykchwexee.ap-southeast-2.es.amazonaws.com/_plugin/kibana/ ``` The 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. ================================================ FILE: docs/docs/examples/logging/efk/local_es/elasticsearch.yaml ================================================ --- clusterName: "elasticsearch" nodeGroup: "master" # The service that non master groups will try to connect to when joining the cluster # This should be set to clusterName + "-" + nodeGroup for your master group masterService: "" # Elasticsearch roles that will be applied to this nodeGroup # These will be set as environment variables. E.g. node.master=true roles: master: "true" ingest: "true" data: "true" replicas: 3 minimumMasterNodes: 2 esMajorVersion: "" # Allows you to add any config files in /usr/share/elasticsearch/config/ # such as elasticsearch.yml and log4j2.properties esConfig: {} # elasticsearch.yml: | # key: # nestedkey: value # log4j2.properties: | # key = value # Extra environment variables to append to this nodeGroup # This will be appended to the current 'env:' key. You can use any of the kubernetes env # syntax here extraEnvs: [] # - name: MY_ENVIRONMENT_VAR # value: the_value_goes_here # A list of secrets and their paths to mount inside the pod # This is useful for mounting certificates for security and for mounting # the X-Pack license secretMounts: [] # - name: elastic-certificates # secretName: elastic-certificates # path: /usr/share/elasticsearch/config/certs image: "docker.elastic.co/elasticsearch/elasticsearch" imageTag: "7.1.2" imagePullPolicy: "IfNotPresent" podAnnotations: {} # iam.amazonaws.com/role: es-cluster # additionals labels labels: {} esJavaOpts: "-Xmx1g -Xms1g" resources: requests: cpu: "100m" memory: "1000Mi" limits: cpu: "100m" memory: "1000Mi" initResources: {} # limits: # cpu: "25m" # # memory: "128Mi" # requests: # cpu: "25m" # memory: "128Mi" sidecarResources: {} # limits: # cpu: "25m" # # memory: "128Mi" # requests: # cpu: "25m" # memory: "128Mi" networkHost: "0.0.0.0" volumeClaimTemplate: accessModes: [ "ReadWriteOnce" ] resources: requests: storage: 10Gi rbac: create: false serviceAccountName: "" podSecurityPolicy: create: false name: "" spec: privileged: true fsGroup: rule: RunAsAny runAsUser: rule: RunAsAny seLinux: rule: RunAsAny supplementalGroups: rule: RunAsAny volumes: - secret - configMap - persistentVolumeClaim persistence: enabled: true annotations: {} extraVolumes: "" # - name: extras # emptyDir: {} extraVolumeMounts: "" # - name: extras # mountPath: /usr/share/extras # readOnly: true extraContainers: "" # - name: do-something # image: busybox # command: ['do', 'something'] extraInitContainers: "" # - name: do-something # image: busybox # command: ['do', 'something'] # This is the PriorityClass settings as defined in # https://kubernetes.io/docs/concepts/configuration/pod-priority-preemption/#priorityclass priorityClassName: "" # By default this will make sure two pods don't end up on the same node # Changing this to a region would allow you to spread pods across regions antiAffinityTopologyKey: "kubernetes.io/hostname" # Hard means that by default pods will only be scheduled if there are enough nodes for them # and that they will never end up on the same node. Setting this to soft will do this "best effort" #antiAffinity: "hard" antiAffinity: "soft" # This is the node affinity settings as defined in # https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#node-affinity-beta-feature nodeAffinity: {} # The default is to deploy all pods serially. By setting this to parallel all pods are started at # the same time when bootstrapping the cluster podManagementPolicy: "Parallel" protocol: http httpPort: 9200 transportPort: 9300 service: labels: {} labelsHeadless: {} type: ClusterIP nodePort: "" annotations: {} httpPortName: http transportPortName: transport loadBalancerSourceRanges: [] updateStrategy: RollingUpdate # This is the max unavailable setting for the pod disruption budget # The default value of 1 will make sure that kubernetes won't allow more than 1 # of your pods to be unavailable during maintenance maxUnavailable: 1 podSecurityContext: fsGroup: 1000 runAsUser: 1000 # The following value is deprecated, # please use the above podSecurityContext.fsGroup instead fsGroup: "" securityContext: capabilities: drop: - ALL # readOnlyRootFilesystem: true runAsNonRoot: true runAsUser: 1000 # How long to wait for elasticsearch to stop gracefully terminationGracePeriod: 120 sysctlVmMaxMapCount: 262144 readinessProbe: failureThreshold: 3 initialDelaySeconds: 60 periodSeconds: 30 successThreshold: 3 timeoutSeconds: 15 # https://www.elastic.co/guide/en/elasticsearch/reference/current/cluster-health.html#request-params wait_for_status clusterHealthCheckParams: "wait_for_status=green&timeout=1s" ## Use an alternate scheduler. ## ref: https://kubernetes.io/docs/tasks/administer-cluster/configure-multiple-schedulers/ ## schedulerName: "" imagePullSecrets: [] nodeSelector: {} tolerations: [] # Enabling this will publically expose your Elasticsearch instance. # Only enable this if you have security enabled on your cluster ingress: enabled: false annotations: {} # kubernetes.io/ingress.class: nginx # kubernetes.io/tls-acme: "true" path: / hosts: - chart-example.local tls: [] # - secretName: chart-example-tls # hosts: # - chart-example.local nameOverride: "" fullnameOverride: "" # https://github.com/elastic/helm-charts/issues/63 masterTerminationFix: false lifecycle: {} # preStop: # exec: # command: ["/bin/sh", "-c", "echo Hello from the postStart handler > /usr/share/message"] # postStart: # exec: # command: # - bash # - -c # - | # #!/bin/bash # # Add a template to adjust number of shards/replicas # TEMPLATE_NAME=my_template # INDEX_PATTERN="logstash-*" # SHARD_COUNT=8 # REPLICA_COUNT=1 # ES_URL=http://localhost:9200 # while [[ "$(curl -s -o /dev/null -w '%{http_code}\n' $ES_URL)" != "200" ]]; do sleep 1; done # 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'}}' sysctlInitContainer: enabled: true keystore: [] ================================================ FILE: docs/docs/examples/logging/efk/managed_es/fluentbit.yaml ================================================ --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: fluent-bit-read rules: - apiGroups: [""] resources: - namespaces - pods verbs: ["get", "list", "watch"] --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: fluent-bit-read roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: fluent-bit-read subjects: - kind: ServiceAccount name: fluent-bit namespace: ${KUBE_NAMESPACE} --- apiVersion: v1 kind: ConfigMap metadata: name: fluent-bit-config namespace: ${KUBE_NAMESPACE} labels: k8s-app: fluent-bit data: # Configuration files: server, input, filters and output # ====================================================== fluent-bit.conf: | [SERVICE] Flush 1 Log_Level info Daemon off Parsers_File parsers.conf HTTP_Server On HTTP_Listen 0.0.0.0 HTTP_Port 2020 @INCLUDE input-kubernetes.conf @INCLUDE filter-kubernetes.conf @INCLUDE output-elasticsearch.conf input-kubernetes.conf: | [INPUT] Name tail Tag kube.* Path /var/log/containers/*.log Parser docker DB /var/log/flb_kube.db Mem_Buf_Limit 50MB Skip_Long_Lines On Refresh_Interval 10 filter-kubernetes.conf: | [FILTER] Name kubernetes Match kube.* Kube_URL https://kubernetes.default.svc:443 Kube_CA_File /var/run/secrets/kubernetes.io/serviceaccount/ca.crt Kube_Token_File /var/run/secrets/kubernetes.io/serviceaccount/token Kube_Tag_Prefix kube.var.log.containers. Merge_Log On Merge_Log_Key log_processed K8S-Logging.Parser On K8S-Logging.Exclude Off output-elasticsearch.conf: | [OUTPUT] Name es Match * Host ${ES_HOST} Port ${ES_PORT} TLS On AWS_Auth On AWS_Region ${AW_REGION} Retry_Limit 6 parsers.conf: | [PARSER] Name bitbucket_log Format regex Regex ^(?