Deploy Data Center products with the AWS Quick Start template

1. Clone the Quick Start templates (including all of its submodules) to your local machine. From the command line, run:

   git clone --recurse-submodules https://github.com/aws-quickstart/quickstart-atlassian-jira.git

2. (Optional) The Quick Start templates repository uses the directory structure required by the Quick Start interface. If needed (for example, to minimize storage costs), you can remove all other files except the following:

   quickstart-atlassian-jira 
├─ submodules 
│ └─ quickstart-atlassian-services 
│ └─ templates 
│ └── quickstart-vpc-for-atlassian-services.yaml 
└─ templates 
├── quickstart-jira-dc-with-vpc.template.yaml 
└── quickstart-jira-dc.template.yaml

3. Install and set up the AWS Command Line Interface. This tool will allow you to create an S3 bucket and upload content to it.

4. Create an S3 bucket in your region:

   aws s3 mb s3://<bucket-name> --region <AWS_REGION>

At this point, you can now upload the Quick Start templates to your own S3 bucket. Before you do, you'll have to choose which Quick Start template you’ll be using:

• quickstart-jira-dc-with-vpc.template.yaml: use this for deploying into a new ASI (end-to-end deployment).

• quickstart-jira-dc.template.yaml: use this for deploying into an existing ASI.

1. In the template you’ve chosen, the QSS3BucketName default value is set to aws-quickstart. Replace this default with the name of your S3 bucket.

2. Go into the parent directory of your local clone of the Quick Start templates. From there, upload all the files in local clone to your S3 bucket:

   aws s3 cp quickstart-atlassian-jira s3://<bucket-name> --recursive --acl public-read

3. Once you’ve uploaded everything, you’re ready to deploy your production stack from your S3 bucket. Go to Cloudformation > Create Stack. When specifying a template, paste in the Object URL of the Quick Start template you’ll be using.

1. Clone the Quick Start templates (including all of its submodules) to your local machine. From the command line, run:

   git clone --recurse-submodules https://github.com/aws-quickstart/quickstart-atlassian-confluence.git

2. (Optional) The Quick Start templates repository uses the directory structure required by the Quick Start interface. If needed (for example, to minimize storage costs), you can remove all other files except the following:

   quickstart-atlassian-confluence 
├─ submodules 
│ └─ quickstart-atlassian-services 
│ └─ templates 
│ └── quickstart-vpc-for-atlassian-services.yaml 
└─ templates 
├── quickstart-confluence-master-with-vpc.template.yaml 
└── quickstart-confluence-master.template.yaml

3. Install and set up the AWS Command Line Interface. This tool will allow you to create an S3 bucket and upload content to it.

4. Create an S3 bucket in your region:

   aws s3 mb s3://<bucket-name> --region <AWS_REGION>

At this point, you can now upload the Quick Start templates to your own S3 bucket. Before you do, you'll have to choose which Quick Start template you’ll be using:

• quickstart-confluence-master-with-vpc.template.yaml: use this for deploying into a new ASI (end-to-end deployment).

• quickstart-confluence-master.template.yaml: use this for deploying into an existing ASI.

1. In the template you’ve chosen, the QSS3BucketName default value is set to aws-quickstart. Replace this default with the name of your S3 bucket.

2. Go into the parent directory of your local clone of the Quick Start templates. From there, upload all the files in local clone to your S3 bucket:

   aws s3 cp quickstart-atlassian-confluence s3://<bucket-name> --recursive --acl public-read

3. Once you’ve uploaded everything, you’re ready to deploy your production stack from your S3 bucket. Go to Cloudformation > Create Stack. When specifying a template, paste in the Object URL of the Quick Start template you’ll be using.

1. Clone the Quick Start templates (including all of its submodules) to your local machine. From the command line, run:

   git clone --recurse-submodules https://github.com/aws-quickstart/quickstart-atlassian-bitbucket

2. (Optional) The Quick Start templates repository uses the directory structure required by the Quick Start interface. If needed (for example, to minimize storage costs), you can remove all other files except the following:

   quickstart-atlassian-bitbucket 
├─ submodules 
│ └─ quickstart-atlassian-services 
│ └─ templates 
│ └── quickstart-vpc-for-atlassian-services.yaml 
└─ templates 
├── quickstart-bitbucket-dc-with-vpc.template.yaml 
└── quickstart-bitbucket-dc.template.yaml

3. Install and set up the AWS Command Line Interface. This tool will allow you to create an S3 bucket and upload content to it.

4. Create an S3 bucket in your region:

   aws s3 mb s3://<bucket-name> --region <AWS_REGION>

At this point, you can now upload the Quick Start templates to your own S3 bucket. Before you do, you'll have to choose which Quick Start template you’ll be using:

• quickstart-bitbucket-dc-with-vpc.template.yaml: use this for deploying into a new ASI (end-to-end deployment).

• quickstart-bitbucket-dc.template.yaml: use this for deploying into an existing ASI.

1. In the template you’ve chosen, the QSS3BucketName default value is set to aws-quickstart. Replace this default with the name of your S3 bucket.

2. Go into the parent directory of your local clone of the Quick Start templates. From there, upload all the files in local clone to your S3 bucket:

   aws s3 cp quickstart-atlassian-bitbucket s3://<bucket-name> --recursive --acl public-read

3. Once you’ve uploaded everything, you’re ready to deploy your production stack from your S3 bucket. Go to Cloudformation > Create Stack. When specifying a template, paste in the Object URL of the Quick Start template you’ll be using.

1. Clone the Quick Start templates (including all of its submodules) to your local machine. From the command line, run:

   git clone --recurse-submodules https://github.com/aws-quickstart/quickstart-atlassian-crowd.git

2. (Optional)The Quick Start templates repository uses the directory structure required by the Quick Start interface. If needed (for example, to minimize storage costs), you can remove all other files except the following:

   quickstart-atlassian-crowd 
├─ submodules 
│  └─ quickstart-atlassian-services 
│    └─ templates 
│     └── quickstart-vpc-for-atlassian-services.yaml 
└─ templates 
   ├── quickstart-crowd-dc-with-vpc.template.yaml 
   └── quickstart-crowd-dc.template.yaml

3. Install and set up the AWS Command Line Interface. This tool will allow you to create an S3 bucket and upload content to it.

4. Create an S3 bucket in your region:

   aws s3 mb s3://<bucket-name> --region <AWS_REGION>

At this point, you can now upload the Quick Start templates to your own S3 bucket. Before you do, you'll have to choose which Quick Start template you’ll be using:

• quickstart-crowd-dc-with-vpc.template.yaml: use this for deploying into a new ASI (end-to-end deployment).

• quickstart-crowd-dc.template.yaml: use this for deploying into an existing ASI.

1. In the template you’ve chosen, the QSS3BucketName default value is set to aws-quickstart. Replace this default with the name of your S3 bucket.

2. Go into the parent directory of your local clone of the Quick Start templates. From there, upload all the files in local clone to your S3 bucket:

   aws s3 cp quickstart-atlassian-crowd s3://<bucket-name> --recursive --acl public-read

3. Once you’ve uploaded everything, you’re ready to deploy your production stack from your S3 bucket. Go to Cloudformation > Create Stack. When specifying a template, paste in the Object URL of the Quick Start template you’ll be using.

Synchrony setup in Confluence

If you have a Confluence Data Center license, two methods are available for running Synchrony:

• Managed by Confluence (recommended)
  Confluence will automatically launch a Synchrony process on the same node, and manage it for you. No manual setup is required. 

• Standalone Synchrony cluster (managed by you)
  You deploy and manage Synchrony standalone in its own cluster with as many nodes as you need. Significant setup is required. During a rolling upgrade, you'll need to upgrade the Synchrony separately from the Confluence cluster.

If you want simple setup and maintenance, we recommend allowing Confluence to manage Synchrony for you.  If you want full control, or if making sure the editor is highly available is essential, then managing Synchrony in its own cluster may be the right solution for your organisation. 

By default, the Quick Start will configure Synchrony to be managed by Confluence. However, you can use the Quick Start to configure standalone Synchrony. When you do, the Quick Start creates an Auto Scaling group containing one or more Amazon EC2 instances as cluster nodes, running Synchrony. Learn more about the possible Confluence and Synchrony configurations

For Large or XLarge deployments, check out our AWS infrastructure recommendations for application, Synchrony, and database sizing advice. For smaller deployments, you can use instances that meet Confluence's system requirements.  Smaller instance types (micro, small, medium) are generally not adequate for running Confluence.

Internal domain name routing with Route53 Private Hosted Zones

Even if your Confluence site is hosted on AWS, you can still link its DNS with an internal, on-premise DNS server (if you have one). You can do this through Amazon Route 53, creating a link between the public DNS and internal DNS. This will make it easier to access your infrastructure resources (database, shared home, and the like) through friendly domain names. You can make those domain names accessible externally or internally, depending on your DNS preferences.

Step 1: Create a new hosted zone

Create a Private hosted zone in Services > Route 53. The Domain Name is your preferred domain. For the VPC, use the existing Atlassian Standard Infrastructure.

Step 2: Configure your stack to use the hosted zone

Use your deployment’s Quick Start template to point your stack to the hosted zone from step 1. If you’re setting up Confluence for the first time, follow the Quick Start template as below:

1. Under DNS (Optional), enter the name of your hosted zone in the Route 53 Hosted Zone field.

2. Enter your preferred domain sub-domain in the Sub-domain for Hosted Zone field. If you leave it blank, we'll use your stack name as the sub-domain.

3. Follow the prompts to deploy the stack.

If you already have an existing Confluence site, you can also configure your stack through the Quick Start template. To access this template:

1. Go to to Services > CloudFormation in the AWS console

2. Select the stack, and select Update Stack.

3. Under DNS (Optional), enter the name of your hosted zone in the Route 53 Hosted Zone field.

4. Enter your preferred domain sub-domain in the Sub-domain for Hosted Zone field. If you leave it blank, we'll use your stack name as the sub-domain.

5. Follow the prompts to update the stack.

In either case, AWS will generate URLs and Route 53 records for the load balancer, EFS, and database. For example, if your hosted zone is my.hostedzone.com and your stack is named mystack, you can access the database through the URL mystack.db.my.hostedzone.com.

Step 3: Link your DNS server to the Confluence site’s VPC

If you use a DNS server outside of AWS, then you need to link it to your deployment’s VPC (in this case, the Atlassian Standard Infrastructure). This means your DNS server should use Route 53 to resolve all queries to the hosted zone’s preferred domain (in Step 1).

For instructions on how to set this up, see Resolving DNS Queries Between VPCs and Your Network.

If you want to deploy an internal facing Confluence site, using your own DNS server, you can use Amazon Route 53 to create a link between the public DNS and internal DNS. 

1. In Route 53, create a Private hosted zone. For the VPC, you can use the existing Atlassian Services VPC. The domain name is your preferred domain.

2. If you've already set up Confluence, go to Services > CloudFormation in the AWS console, select the stack, and select Update stack. (If you're setting up Confluence for the first time, follow the Quick Start template as below). 

3. Under Other parameters, enter the name of your hosted zone in the Route 53 Hosted Zone field. 

4. Enter your preferred sub-domain or leave the Sub-domain for Hosted Zone field blank and we'll use your stack name as the sub-domain.

5. Follow the prompts to update the stack. We'll then generate the load balancer and EFS url, and create a record in Route 53 for each. 

6. In Confluence, go to Administration > General configuration and update the Confluence base URL to your Route 53 domain. 

7. Set up DNS resolution between your on-premises network and the VPC with the private hosted zone. You can do this with:

   1. an Active Directory (either Amazon Directory Service or Microsoft Active Directory)

   2. a DNS forwarder on EC2 using bind9 or Unbound.

8. Finally, terminate and re-provision each Confluence and Synchrony node to pick up the changes.

For related information on configuring Confluence's base URL, see Configuring the Server Base URL.

Scaling up and down

To increase or decrease the number of Confluence or Synchrony cluster nodes:

1. Sign in to the AWS Management Console, use the region selector in the navigation bar to choose the AWS Region for your deployment, and open the AWS CloudFormation console at https://console.aws.amazon.com/cloudformation/.

2. Select the Stack name of your deployment. This will display your deployment's Stack info. From there, select Update.

3. On the Select template page, leave Use current template selected, and then select Next.

4. On the Specify details page, go to the Cluster nodes section of Parameters. From there, set your desired number of application nodes in the following parameters:

   1. Minimum number of cluster nodes

   2. Maximum number of cluster nodes

5.  Continue to update the stack.

Vertical vs. horizontal scaling

Adding new cluster nodes, especially automatically in response to load spikes, is a great way to increase capacity of a cluster temporarily. Beyond a certain point,  adding very large numbers of cluster nodes will bring diminishing returns. In general, increasing the size of each node (i.e., "vertical" scaling) will be able to handle a greater sustained capacity than increasing the number of nodes (i.e., "horizontal" scaling), especially if the nodes themselves are small. See Infrastructure recommendations for enterprise Confluence instances on AWS for more details. See the AWS documentation for more information on auto scaling groups. 

Connecting to your nodes over SSH

You can perform node-level configuration or maintenance tasks on your deployment through the AWS Systems Manager Sessions Manager. This browser-based terminal lets you access your nodes without any SSH Keys or a Bastion host. For more information, see Getting started with Session Manager.

You can also access your nodes via a Bastion host (if you deployed one). To do this, you'll need your SSH private key file (the PEM file you specified for the Key Name parameter). Remember, this key can access all nodes in your deployment, so keep this key in a safe place.

The Bastion host acts as your "jump box" to any instance in your deployment's internal subnets. That is, access the Bastion host first, and from there access any instance in your deployment. 

The Bastion host's public IP is the BastionPubIp output of your deployment's ATL-BastionStack stack. This stack is nested in your deployment's Atlassian Standard Infrastructure (ASI). To access the Bastion host, use ec2-user as the user name, for example:

• ssh -i keyfile.pem ec2-user@<BastionPubIp>

The ec2-user has sudo access. SSH access is by root isn't allowed.

Upgrading

Consider upgrading to a Long Term Support release (if you're not on one already). Enterprise releases get fixes for critical bugs and security issues throughout its two-year support window. This gives you the option to keep a slower upgrade cadence without sacrificing security or stability. Long Term Support releases are suitable for companies who can't keep up with the frequency at which we ship feature releases.

Here's some useful advice for upgrading your deployment:

1. Before upgrading to a later version of Confluence Data Center, check if your apps are compatible with that version. Update your apps if needed. For more information about managing apps, see Using the Universal Plugin Manager.

2. If you need to keep Confluence Data Center running during your upgrade, we recommend using read-only mode for site maintenance.  Your users will be able to view pages, but not create or change them. 

3. We strongly recommend that you perform the upgrade first in a staging environment before upgrading your production instance. Create a staging environment for upgrading Confluence provides helpful tips on doing so.

When the time comes to upgrade your deployment, perform the following steps:

Step 1: Terminate all running Confluence Data Center application nodes

Set the number of application nodes used by the Confluence Data Center stack to 0. Then, update the stack.

To udpate the stack:

1. In the AWS console, go to Services > CloudFormation. Select your deployment’s stack to view its Stack Details.

2. In the Stack Details screen, select Update stack.

3. From the Select template screen, select Use current template, and select Next.

4. You’ll need to terminate all running nodes. To do that, set the following parameters to 0:

   1. Maximum number of cluster nodes

   2. Minimum number of cluster nodes

5. Select Next. Continue to the next pages, then apply the change using the Update button.

6. Once the update is complete, check that all application nodes have been terminated.

Step 2: Update the version used by your Confluence Data Center stack

Set the number of application nodes used by Confluence Data Center to 1. Configure it to use the version you want. Then, update the stack again.

To update the stack again:

1. From your deployment’s Stack details screen, select Update stack again.

2. From the Select Template screen, select Use current template, then select Next.

3. Set the Version parameter to the version you’re updating to.

4. Configure your stack to use one node. To do that, set the following parameters to 1:

   1. Maximum number of cluster nodes

   2. Minimum number of cluster nodes

5. Select Next. Continue through the next pages, then apply the change using the Update button.

Step 3: Scale up the number of application nodes

You can now scale up your deployment to your original number of application nodes. You can do so for your Synchrony nodes as well, if you have standalone Synchrony. Refer back to Step 1 for instructions on how to re-configure the number of nodes used by your cluster.

Confluence Data Center in AWS currently doesn't allow upgrading an instance without some downtime in between the last cluster node of the old version shutting down and the first cluster node on the new version starting up.  Make sure all existing nodes are terminated before launching new nodes on the new version.

Backing up

We recommend you use the AWS native backup facility, which utilizes snap-shots to back up your Confluence Data Center. For more information, see AWS Backup. 

Migrating your existing Confluence site to AWS

After deploying Confluence on AWS, you might want to migrate your old deployment to it. To do so:

1. Upgrade your existing site to the version you have deployed to AWS (Confluence 6.1 or later).

2. (Optional) If your old database isn't PostgreSQL, you'll need to migrate it. See Migrating to Another Database for instructions. 

3. Back up your PostgreSQL database and your existing <shared-home>/attachments directory.

4. Copy your backup files to /media/atl/confluence/shared-home in your EC2 instance.  

5. Restore your PostgreSQL database dump to your RDS instance with pg_restore.
   See Importing Data into PostgreSQL on Amazon RDS in Amazon documentation for more information on how to do this.   

Administering Bitbucket Data Center in AWS

See Administering Bitbucket Data Center in AWS for information about performing administration tasks on a Bitbucket instance within AWS, including:

• configuring variables when launching Bitbucket in AWS

• maintaining, resizing, upgrading, migrating, and customizing your Bitbucket deployment in AWS

• additional details about the components within the Bitbucket Server AMI

Securing Bitbucket within AWS

AWS is accessed over the public Internet, so it is important to apply appropriate security measures when running Bitbucket Server in AWS. See Best practices for securing Bitbucket in AWS for security guidance on a range of security topics, including Amazon Virtual Private Cloud (VPC), Security Groups, and SSL.

Performance guidelines

To get the best performance out of your Bitbucket deployment in AWS, it's important not to under-provision your instance's CPU, memory, or I/O resources. Whether you choose to deploy Bitbucket Data Center, which offers performance gains via horizontal scaling, or a single node Bitbucket Server instance, we have specific recommendations on choosing AWS EC2 and EBS settings for best performance per node.

If you are using the CloudFormation template, these settings are already included. Otherwise, see Infrastructure recommendations for enterprise Bitbucket instances on AWS.

Mirroring

Smart Mirroring can drastically improve Git clone speeds for distributed teams working with large repositories. For an overview of the benefits to mirroring, see Mirrors. The Bitbucket Data Center FAQ also answers many common questions about smart mirroring (and mirroring in general). 

For detailed instructions, see Set up a mirror.