|
1 | 1 | # ServiceStack mix GitHub Actions |
2 | | -`release.yml` generated from `x mix release-ecr-aws`, this template in designed to help with automating CI deployments to AWS ECS and dedicated AWS ECS cluster. |
3 | | -This is a cheap way to start without an AWS Application Load Balancer (ALB) and also be in a situation that will easier to add one once the web service needs additional scale or high availability. |
| 2 | +`release.yml` generated from `x mix release-ghr-vanilla`, this template in designed to help with CI deployment to a dedicated server with SSH access. |
4 | 3 |
|
5 | 4 | ## Overview |
6 | | -`release.yml` is designed to work with a ServiceStack app templates deploying directly to a single server in a dedicated ECS cluster via templated GitHub Actions. |
| 5 | +`release.yml` is designed to work with a ServiceStack app deploying directly to a single server via SSH. A docker image is built and stored on GitHub's `ghcr.io` docker registry when a GitHub Release is created. |
7 | 6 |
|
8 | | -## Setup |
9 | | -### Create unique ECS cluster |
10 | | -For this setup, it is best to create a separate cluster as cluster will only have the single instance in it running. |
11 | | -This pattern is to start from a good base with AWS ECS and automated CI deployment while avoiding the higher costs of needing to run an application load balancer (ALB). |
| 7 | +GitHub Actions specified in `release.yml` then copy files remotely via scp and use `docker-compose` to run the app remotely via SSH. |
12 | 8 |
|
13 | | -If/when you can justify the cost of an ALB for easier scaling and zero downtime deployment, the GitHub Action `release.yml` can be slightly modified to be used with a re-created or different ECS Service that is configured to be used with an Application Load Balancer and Target Group. |
| 9 | +## Deployment server setup |
| 10 | +To get this working, a server needs to be setup with the following: |
14 | 11 |
|
15 | | -### Elastic IP (optional) |
16 | | -The reason you might want to register this first is because we are only running one EC2 instance and hosting our own `nginx-proxy` on the same instance as the applications. |
17 | | -Since an `A` record will be pointing there, one advantage of not using an auto-assigned IP is that we can reassign the elastic IP if for what ever reason the instance goes down or is lost. |
| 12 | +- SSH access |
| 13 | +- docker |
| 14 | +- docker-compose |
| 15 | +- ports 443 and 80 for web access of your hosted application |
18 | 16 |
|
19 | | -## Launch to EC2 Instance |
20 | | -When launching the EC2 instance, you'll need to select an 'ECS optimized' AMI as the image used for your instance. |
21 | | -### Choose AMI |
22 | | -The easiest way to find the latest Amazon Linux 2 image for this is to go to the [AWS documentation for ECS-optimized AMIs and look up your region here](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-optimized_AMI.html#ecs-optimized-ami-linux). |
| 17 | +This can be your own server or any cloud hosted server like Digital Ocean, AWS, Azure etc. |
23 | 18 |
|
24 | | -Using the AMI ID (starts with `ami-`) at the bottom, search in the 'Community AMIs' tab on the first step of the `Launch EC2 Instance` wizard. |
| 19 | +When setting up your server, you'll want to use a dedicated SSH key for access to be used by GitHub Actions. GitHub Actions will need the *private* SSH key within a GitHub Secret to authenticate. This can be done via ssh-keygen and copying the public key to the authorized clients on the server. |
25 | 20 |
|
26 | | -### Choose Instance Type |
27 | | -A t2.micro or larger will work fine, this pattern can be used to host multiple applications on the 1 server so if the number of applications gets larger, you might need a larger instance type. |
28 | | -> Note this pattern is suitable for testing prototypes or low traffic applications as it is cost effective and makes it easy to bundle multiple apps onto 1 EC2 instance. |
29 | | -
|
30 | | -### Configure Instance |
31 | | -Under `IAM role`, use the `ecsInstanceRole`, if this is not available, see [AWS documentation for the process of checking if it exists and creating it if needed](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/instance_IAM_role.html). |
32 | | - |
33 | | -If you are *not* using your own generated Elastic IP, select `Enabled` for `Auto-assign Public IP`. |
34 | | - |
35 | | -You will also want to add the following Userdata script (in the `Configure` step of the launch wizard) with your own `ECS_CLUSTER` value. This tells the ecs-agent running on the instance which ECS cluster the instance should join. |
36 | | - |
37 | | -```bash |
38 | | -#!/bin/bash |
39 | | -cat <<EOS >/etc/ecs/ecs.config |
40 | | -ECS_CLUSTER=my-cluster |
41 | | -ECS_AVAILABLE_LOGGING_DRIVERS=["awslogs", "syslog"] |
42 | | -ECS_ENABLE_CONTAINER_METADATA=true |
43 | | -EOS |
44 | | -``` |
45 | | - |
46 | | -Note down your cluster name as it will need to be used to create the cluster in ECS before it is visible. |
47 | | -See [`ECS Container Agent Configuration`](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-agent-config.html) for more information. |
48 | | - |
49 | | -### Add Storage |
50 | | -The default of 30gb is fine but take into account how large/how many applications you'll have running. |
51 | | - |
52 | | -### Configure Security Groups |
53 | | -You'll want to expose at least ports 80 and 443. |
54 | | - |
55 | | -### Setup Docker-compose and nginx-proxy |
56 | 21 | To let your server handle multiple ServiceStack applications and automate the generation and management of TLS certificates, an additional docker-compose file is provided via the `x mix` template, `nginx-proxy-compose.yml`. This docker-compose file is ready to run and can be copied to the deployment server. |
57 | | -> This is done via docker-compose rather than via ECS itself for simplicity. |
58 | | -
|
59 | | -First you'll need to install `docker-compose`. |
60 | | - |
61 | | -```bash |
62 | | -sudo curl -L "https://github.com/docker/compose/releases/download/1.27.4/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose |
63 | | -sudo chmod +x /usr/local/bin/docker-compose |
64 | | -``` |
65 | | -Run `docker-compose --version` to confirm. |
66 | | - |
67 | | -To copy you can use scp or just creating a new file via server text editor to copy the short YML file over. For this example, we are going to copy it straight to the ~/ (home) directory. |
68 | | - |
69 | | -```bash |
70 | | -scp -i <path to private ssh key> ./nginx-proxy-compose.yml ec2-user@<server_floating_ip>:~/nginx-proxy.compose.yml |
71 | | -``` |
72 | 22 |
|
73 | 23 | For example, once copied to remote `~/nginx-proxy-compose.yml`, the following command can be run on the remote server. |
74 | 24 |
|
75 | 25 | ``` |
76 | 26 | docker-compose -f ~/nginx-proxy-compose.yml up -d |
77 | 27 | ``` |
78 | 28 |
|
79 | | -This will run an nginx reverse proxy along with a companion container that will watch for additional containers in the same docker network and attempt to initialize them with valid TLS certificates. This includes containers created and managed by the ECS agent. |
80 | | -> If the container doesn't have the environment variable `VIRTUAL_HOST` set, it will be ignored. |
| 29 | +This will run an nginx reverse proxy along with a companion container that will watch for additional containers in the same docker network and attempt to initialize them with valid TLS certificates. |
81 | 30 |
|
82 | 31 | ## GitHub Repository setup |
83 | 32 | The `release.yml` assumes 6 secrets have been setup. |
84 | 33 |
|
85 | | -- AWS_ACCESS_KEY_ID - AWS access key for programmatic access to AWS APIs. |
86 | | -- AWS_SECRET_ACCESS_KEY - AWS access secrets for programmatic access to AWS APIs. |
87 | | -- AWS_REGION - default region for AWS API calls. |
88 | | -- AWS_ECS_CLUSTER - Cluster name in ECS, this should match the value in your Userdata. |
89 | | -- HOST_DOMAIN - Domain/sub-domain of your application, eg `vitepress-docs.example.com` . |
| 34 | +- CR_PAT - GitHub Personal Token with read/write access to packages. |
| 35 | +- DEPLOY_HOST - hostname used to SSH to, this can either be an IP address or subdomain with A record pointing to the server. |
| 36 | +- DEPLOY_PORT - SSH port, usually `22`. |
| 37 | +- DEPLOY_USERNAME - the username being logged into via SSH. Eg, `ubuntu`, `ec2-user`, `root` etc. |
| 38 | +- DEPLOY_KEY - SSH private key used to remotely access deploy server/app host. |
90 | 39 | - LETSENCRYPT_EMAIL - Email address, required for Let's Encrypt automated TLS certificates. |
91 | 40 |
|
92 | 41 | These secrets can use the [GitHub CLI](https://cli.github.com/manual/gh_secret_set) for ease of creation. Eg, using the GitHub CLI the following can be set. |
93 | 42 |
|
94 | 43 | ```bash |
95 | | -gh secret set AWS_ACCESS_KEY_ID -b"<AWS_ACCESS_KEY_ID>" |
96 | | -gh secret set AWS_SECRET_ACCESS_KEY -b"<AWS_SECRET_ACCESS_KEY>" |
97 | | -gh secret set AWS_REGION -b"<AWS_REGION, eg us-east-1>" |
98 | | -gh secret set AWS_ECS_CLUSTER -b"<AWS_ECS_CLUSTER, eg vitepress-docss>" |
99 | | -gh secret set HOST_DOMAIN -b"<HOST_DOMAIN, eg vitepress-docs.example.com>" |
100 | | -gh secret set LETSENCRYPT_EMAIL -b"<LETSENCRYPT_EMAIL, eg me@example.com>" |
| 44 | +gh secret set CR_PAT -b"<CR_PAT, Container Registry Personal Access Token>" |
| 45 | +gh secret set DEPLOY_HOST -b"<DEPLOY_HOST, domain or subdomain for your application and server host.>" |
| 46 | +gh secret set DEPLOY_PORT -b"<DEPLOY_PORT, eg SSH port, usually 22>" |
| 47 | +gh secret set DEPLOY_USERNAME -b"<DEPLOY_USERNAME, the username being logged into via SSH. Eg, `ubuntu`, `ec2-user`, `root` etc.>" |
| 48 | +gh secret set DEPLOY_KEY -b"<DEPLOY_KEY, SSH private key used to remotely access deploy server/app host.>" |
| 49 | +gh secret set LETSENCRYPT_EMAIL -b"<LETSENCRYPT_EMAIL, Email address for your TLS certificate generation, eg me@example.com>" |
101 | 50 | ``` |
102 | 51 |
|
103 | 52 | These secrets are used to populate variables within GitHub Actions and other configuration files. |
104 | 53 |
|
105 | | -For the AWS access, a separate user specifically for deploying via GitHub Actions should be used. |
106 | | - |
107 | | -The policies required for the complete initial setup will be: |
108 | | -- `AmazonEC2ContainerRegistryFullAccess` |
109 | | -- `AmazonECS_FullAccess` |
110 | | - |
111 | | -Once the application is successfully deployed the first time, reduced access for both ECR and ECS can be used instead. For application updates, the GitHub Action can use the following policy. |
112 | | - |
113 | | -```json |
114 | | -{ |
115 | | - "Version": "2012-10-17", |
116 | | - "Statement": [ |
117 | | - { |
118 | | - "Sid": "VisualEditor0", |
119 | | - "Effect": "Allow", |
120 | | - "Action": [ |
121 | | - "ecr:GetRegistryPolicy", |
122 | | - "ecr:PutImageTagMutability", |
123 | | - "ecr:GetDownloadUrlForLayer", |
124 | | - "ecr:DescribeRegistry", |
125 | | - "ecr:GetAuthorizationToken", |
126 | | - "ecr:ListTagsForResource", |
127 | | - "ecr:UploadLayerPart", |
128 | | - "ecr:ListImages", |
129 | | - "ecr:PutImage", |
130 | | - "ecr:UntagResource", |
131 | | - "ecr:BatchGetImage", |
132 | | - "ecr:CompleteLayerUpload", |
133 | | - "ecr:DescribeImages", |
134 | | - "ecr:TagResource", |
135 | | - "ecr:DescribeRepositories", |
136 | | - "ecr:InitiateLayerUpload", |
137 | | - "ecr:BatchCheckLayerAvailability", |
138 | | - "ecr:ReplicateImage", |
139 | | - "ecr:GetRepositoryPolicy", |
140 | | - "ecs:SubmitTaskStateChange", |
141 | | - "ecs:UpdateContainerInstancesState", |
142 | | - "ecs:RegisterContainerInstance", |
143 | | - "ecs:DescribeTaskDefinition", |
144 | | - "ecs:DescribeClusters", |
145 | | - "ecs:ListServices", |
146 | | - "ecs:UpdateService", |
147 | | - "ecs:ListTasks", |
148 | | - "ecs:ListTaskDefinitionFamilies", |
149 | | - "ecs:RegisterTaskDefinition", |
150 | | - "ecs:SubmitContainerStateChange", |
151 | | - "ecs:StopTask", |
152 | | - "ecs:DescribeServices", |
153 | | - "ecs:ListContainerInstances", |
154 | | - "ecs:DescribeContainerInstances", |
155 | | - "ecs:DeregisterContainerInstance", |
156 | | - "ecs:TagResource", |
157 | | - "ecs:DescribeTasks", |
158 | | - "ecs:UntagResource", |
159 | | - "ecs:ListTaskDefinitions", |
160 | | - "ecs:ListClusters" |
161 | | - ], |
162 | | - "Resource": "*" |
163 | | - } |
164 | | - ] |
165 | | -} |
166 | | -``` |
167 | | -> Further permission reduction can be done by reducing what resources can be accessed. |
168 | | -> Application permissions can be controlled via `taskRoleArn`, see [AWS docs for details](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-iam-roles.html). |
169 | | -
|
170 | | -## What's the process of the `release.yml`? |
| 54 | +## What's the process of `release.yml`? |
171 | 55 |
|
172 | | - |
| 56 | + |
0 commit comments