diff --git a/content/amazon-ec2-spot-cicd-workshop/gitlab-spot/prep.md b/content/amazon-ec2-spot-cicd-workshop/gitlab-spot/010-prep.md similarity index 53% rename from content/amazon-ec2-spot-cicd-workshop/gitlab-spot/prep.md rename to content/amazon-ec2-spot-cicd-workshop/gitlab-spot/010-prep.md index 0d059910..21957d24 100644 --- a/content/amazon-ec2-spot-cicd-workshop/gitlab-spot/prep.md +++ b/content/amazon-ec2-spot-cicd-workshop/gitlab-spot/010-prep.md @@ -1,16 +1,8 @@ +++ title = "Workshop Preparation" -weight = 20 +weight = 10 +++ -You should now have the CloudFormation stack with GitLab opened. If not, refer to [**Starting the workshop**](before.html) section to see the steps to get to that page. - -### Save GitLab access details - -Switch to the **Outputs** tab and save all the information in the table to a text file. You will need it in the later steps of this workshop. - -![CloudFormation Console Screenshot: Stack outputs](/images/gitlab-spot/AWSConsole-CloudFormationStackOutput.png) - ### Log in to AWS Cloud9 environment You can execute the steps of this workshop directly on your workstation, but then you will need to make sure that you have the command-line tools for Git, Terraform, kubectl and AWS CLI installed. Instead of that, to not change any local settings, we recommend to use [AWS Cloud9](https://aws.amazon.com/cloud9/): a cloud IDE where you can get access to the terminal and install all the required tools. @@ -18,13 +10,11 @@ You can execute the steps of this workshop directly on your workstation, but the A Cloud9 environment has already been provisioned for you in the CloudFormation template (created in the [**Starting the workshop**](before.html) section). You will now log in to it and do the final configuration steps: disable the AWS managed temporary credentials and download the required workshop files. 1. In the AWS Console enter **Cloud9** in the search box at the top of the screen and open the service. -2. On the **Your environments** page find the environment called like `GitLabWorkshopC9Instance-...` and click the **Open IDE** button for it: +2. On the **Your environments** page find the environment called like `GitLabWorkshopC9Instance-...` and click the **Open IDE** button for it. ![AWS Console Screenshot: Cloud9 Environment](/images/gitlab-spot/AWSConsole-Cloud9Environment.png) -3. When the environment comes up, close all tabs inside it and open a new terminal by clicking **+** > **New Terminal**, you should see a screen like this: - -![Cloud9 Environment Screenshot: Initial view](/images/gitlab-spot/Cloud9-Initial.png) +3. When the environment comes up, close all tabs inside it and open a new terminal by clicking **+** > **New Terminal**. 4. Open preferences tab by choosing the cogwheel icon at the top-right corner of the screen. Then choose **AWS Settings** in the navigation pane. 5. Disable **AWS managed temporary credentials** toggle: @@ -32,22 +22,41 @@ A Cloud9 environment has already been provisioned for you in the CloudFormation ![Cloud9 Screenshot: Preferences](/images/gitlab-spot/Cloud9-Preferences.png) 6. Close the **Preferences** tab and in the terminal tab, execute the following command to verify that you are using the correct role (in the output you should see `GitLabWorkshopC9Role` and green `OK`): - ``` aws sts get-caller-identity --query Arn | grep GitLabWorkshopC9Role && echo -e "\033[0;32mOK\033[0m" || echo -e "\033[0;31mNOT OK\033[0m" ``` ![Cloud9 Screenshot: Caller identity](/images/gitlab-spot/Cloud9-CallerIdentity.png) -7. Now you will upload the SSH key you saved in the previous section. Choose **File** > **Upload Local Files...**. -8. In the popup page choose **Select files** and select the file `ee-default-keypair.pem` that you downloaded previously. -9. Make sure the file appeared in the file tree on the left, close the popup page, and modify the file permissions by executing the following command in the terminal: +7. During the workshop, you will need to refer to the identifiers of the resources created by the CloudFormation stack you deployed. To reduce copy and paste across the CloudFormation console and the Cloud9 environment, you will load the CloudFormation Stack Outputs to environment variables. Configure the stack_name environment variable with the name of your CloudFormation template: +``` +export stack_name=mod-gitlab-spot-workshop +``` + +8. Now, load the CloudFormation stack outputs on environment variables running the following commands: +``` +export AWS_REGION=$(curl --silent http://169.254.169.254/latest/dynamic/instance-identity/document | jq -r .region) +for output in $(aws cloudformation describe-stacks --stack-name $stack_name --query 'Stacks[].Outputs[].OutputKey' --output text) +do + export $output=$(aws cloudformation describe-stacks --stack-name $stack_name --query 'Stacks[].Outputs[?OutputKey==`'$output'`].OutputValue' --output text) >> ~/.bash_profile + eval "echo $output : \"\$$output\"" + + eval "echo export $output=\"\$$output\"" >> ~/.bash_profile +done +. ~/.bash_profile +``` +If successful, the output should be similar to the following: ``` -chmod 400 ~/environment/ee-default-keypair.pem +Subnet1 : subnet-0225d837e8401e3a7 +VPC : vpc-0cef9a85fe90459e6 +GitLabPassword : 5HfKdkUxc880EDnV +GitLabURL : https://d1in48s0v2ygmm.cloudfront.net +GitLabCacheBucket : mod-gitlab-spot-workshop-gitlabcachebucket-aoggbfq6go76 +Subnet1Zone : us-east-1a ``` -10. Finally, enable Cloud9 to show hidden files (you will need it to modify the scripts of GitLab CI/CD later). To do this choose the small cogwheel icon right above the file tree and choose **Show Hidden Files** if it has not been enabled yet (if there is a tick to the left of it, do not click again, as it will disable the display of hidden files): +9. Finally, enable Cloud9 to show hidden files (you will need it to modify the scripts of GitLab CI/CD later). To do this choose the small cogwheel icon right above the file tree and choose **Show Hidden Files** if it has not been enabled yet (if there is a tick to the left of it, do not click again, as it will disable the display of hidden files): ![Cloud9 Screenshot: Show hidden files](/images/gitlab-spot/Cloud9-ShowHiddenFiles.png) diff --git a/content/amazon-ec2-spot-cicd-workshop/gitlab-spot/lab1.md b/content/amazon-ec2-spot-cicd-workshop/gitlab-spot/020-create-gitlab-repo.md similarity index 83% rename from content/amazon-ec2-spot-cicd-workshop/gitlab-spot/lab1.md rename to content/amazon-ec2-spot-cicd-workshop/gitlab-spot/020-create-gitlab-repo.md index d11c3fde..4cc5a6db 100644 --- a/content/amazon-ec2-spot-cicd-workshop/gitlab-spot/lab1.md +++ b/content/amazon-ec2-spot-cicd-workshop/gitlab-spot/020-create-gitlab-repo.md @@ -1,19 +1,23 @@ +++ title = "Create a GitLab repository" -weight = 30 +weight = 20 +++ -In this lab you will create a new repository in GitLab and configure it in AWS Cloud9. Then you will create the source code of the demo app and commit it into the repository, but before you configure the actual CI/CD in the next lab, will not push it. +In this lab, you will create a new repository in GitLab and configure it in AWS Cloud9. Next, you will create the source code of the demo app and commit it into the repository. ### Log in to GitLab -1. Open a new browser tab and proceed to GitLab URL: use the output value **GitLabURL** that you saved [**Workshop Preparation**](prep.html). -2. Log in to GitLab with username `root` and the password from **GitLabPassword** output value. +1. Run below command to get GitLab URL and password from saved environment variables: +``` +echo GitLabURL = $GitLabURL +echo GitLabPassword = $GitLabPassword +``` +2. Open a new browser tab and proceed to GitLab URL. +3. Log in to GitLab with username `root` and the password from **GitLabPassword** output value. ### Create a new repository +**Challenge:** If you are familiar with GitLab, then test your knowledge by creating a new empty private repository called `GitLab Spot Workshop`. -In GitLab create a new empty private repository called `GitLab Spot Workshop`. - -{{%expand "Click to reveal detailed instructions" %}} +{{%expand "Click to reveal the instructions" %}} 1. Choose **New project** on the **Projects** page. 2. Choose **Create blank project**. 3. In the **Project name** field type `GitLab Spot Workshop`, in the dropdown next to **Project URL** select `root` user, and unmark the checkbox **Initialize repository with a README**. Leave the rest values as default, and choose **Create project**: diff --git a/content/amazon-ec2-spot-cicd-workshop/gitlab-spot/lab2.md b/content/amazon-ec2-spot-cicd-workshop/gitlab-spot/030-configure-gitlab-runners-on-spot.md similarity index 66% rename from content/amazon-ec2-spot-cicd-workshop/gitlab-spot/lab2.md rename to content/amazon-ec2-spot-cicd-workshop/gitlab-spot/030-configure-gitlab-runners-on-spot.md index d43884ca..04bac360 100644 --- a/content/amazon-ec2-spot-cicd-workshop/gitlab-spot/lab2.md +++ b/content/amazon-ec2-spot-cicd-workshop/gitlab-spot/030-configure-gitlab-runners-on-spot.md @@ -1,23 +1,41 @@ +++ title = "Configure GitLab runners on Spot instances" chapter = false -weight = 40 +weight = 30 +++ -In this lab you will configure GitLab CI/CD runners using **GitLab HA Scaling Runner Vending Machine for AWS** solution. You can find more about its features at https://gitlab.com/guided-explorations/aws/gitlab-runner-autoscaling-aws-asg/-/blob/main/FEATURES.md. It is built using Infrastructure as Code (IaC) with AWS CloudFormation, but you can implement similar logic using any IaC solution of your choice. +In this lab you will configure GitLab CI/CD runners using **GitLab HA Scaling Runner Vending Machine for AWS** solution. You can find more about its features [**here**](https://gitlab.com/guided-explorations/aws/gitlab-runner-autoscaling-aws-asg/-/blob/main/FEATURES.md). It is built using Infrastructure as Code (IaC) with AWS CloudFormation, but you can implement similar logic using any IaC solution of your choice. -There are also other ways to create GitLab runners on spot instances that we are not reviewing in this workshop: using Docker Machine, runners inside containers in a Kubernetes cluster with the worker nodes on spot instances (we will deploy such cluster for application testing, but not for executing the runners) or in Amazon ECS with Fargate Spot. +There are also other ways to create GitLab runners on spot instances that we are not reviewing in this workshop: using Docker Machine, runners inside containers in a Kubernetes cluster with the worker nodes on spot instances, or in Amazon ECS with Fargate Spot. ### Create an IAM role for GitLab Runners -You will now create a new IAM role that has access to Amazon EKS, Amazon S3, AWS Systems Manager, Amazon EC2 Auto Scaling, and Amazon ECR, which the GitLab Runners will need to build and deploy the demo app. +1. Create the trust policy document named ec2-role-trust-policy.json. +``` +cat << EOF > ~/environment/ec2-role-trust-policy.json +{ + "Version": "2012-10-17", + "Statement": [ + { + "Effect": "Allow", + "Principal": { "Service": "ec2.amazonaws.com"}, + "Action": "sts:AssumeRole" + } + ] +} +EOF +``` -1. In the AWS Console enter **IAM** in the search box at the top of the screen and open the service. -2. Choose **Policies** in the navigation pane. -3. Choose **Create Policy**. -4. Switch to **JSON** tab and paste the below policy into the editor window: +2. Create the **gitlab-runner** role and specify the trust policy that you created using the create-role command. +``` +aws iam create-role \ + --role-name gitlab-runner \ + --assume-role-policy-document file://~/environment/ec2-role-trust-policy.json +``` +3. Create **gitlab-runner-policy.json** access policy document that grants access to Amazon EKS, Amazon S3, AWS Systems Manager, Amazon EC2 Auto Scaling, and Amazon ECR, which the GitLab Runners will need to build and deploy the demo app. ``` +cat << EOF > ~/environment/gitlab-runner-policy.json { "Version": "2012-10-17", "Statement": [ @@ -107,30 +125,52 @@ You will now create a new IAM role that has access to Amazon EKS, Amazon S3, AWS } ] } +EOF ``` -5. Choose **Next: Tags**. -6. Choose **Next: Review**. -7. In the **Name** field type `GitLabRunnerPolicy` and choose **Create policy**: +4. Attach the inline access policy to the role using the put-role-policy command: +``` +aws iam put-role-policy \ + --role-name gitlab-runner \ + --policy-name gitlab-runner-access \ + --policy-document file://~/environment/gitlab-runner-policy.json +``` -![IAM Console Screenshot: Create GitLabRunnerPolicy policy](/images/gitlab-spot/AWSConsole-IAMCreatePolicy.png) +5. Attach the managed access policy to the role using the attach-role-policy command: +``` +aws iam attach-role-policy \ +--policy-arn arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy \ +--role-name gitlab-runner -8. In the navigation pane choose **Roles** -9. Choose **Create role**. -10. In the **Use case** section select **EC2** and choose **Next**. -11. In the **Permissions policies** table find the following policies one-by-one and select each of them: - - `GitLabRunnerPolicy` - - `AmazonSSMManagedInstanceCore` - - `CloudWatchAgentServerPolicy` - - `AmazonSSMAutomationRole` - - `AmazonSSMMaintenanceWindowRole` +aws iam attach-role-policy \ +--policy-arn arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore \ +--role-name gitlab-runner + +aws iam attach-role-policy \ +--policy-arn arn:aws:iam::aws:policy/service-role/AmazonSSMAutomationRole \ +--role-name gitlab-runner + +aws iam attach-role-policy \ +--policy-arn arn:aws:iam::aws:policy/service-role/AmazonSSMMaintenanceWindowRole \ +--role-name gitlab-runner +``` + +6. Create an instance profile named gitlab-runner-profile using the create-instance-profile command. +``` +aws iam create-instance-profile --instance-profile-name gitlab-runner +``` + +7. Add the gitlab-runner role to the gitlab-runner instance profile. +``` +aws iam add-role-to-instance-profile \ + --instance-profile-name gitlab-runner \ + --role-name gitlab-runner +``` {{% notice warning %}} Note that here you are assigning permission policies as required for the demo app. In a real Production environment you should always follow the least privilege principle. You can find the best practices in [AWS Blogs](https://aws.amazon.com/blogs/security/techniques-for-writing-least-privilege-iam-policies/). {{% /notice %}} -12. Make sure you have 5 policies selected and choose **Next**. -13. In the **Role name** field type `GitLabRunner` and choose **Create role**. ### Deploy the CloudFormation stack @@ -142,23 +182,25 @@ You will now get the runner configuration information from GitLab and then start ![GitLab Screenshot: Runners configuration](/images/gitlab-spot/GitLab-RunnersRegistration.png) -4. Download the CloudFormation template latest version located at https://gitlab.com/guided-explorations/aws/gitlab-runner-autoscaling-aws-asg/-/blob/main/GitLabElasticScalingRunner.cf.yml. +4. Download the CloudFormation template latest version located [**here**](https://gitlab.com/guided-explorations/aws/gitlab-runner-autoscaling-aws-asg/-/blob/main/GitLabElasticScalingRunner.cf.yml). 5. Return to the browser tab with CloudFormation or open it again using the search box at the top. 6. Choose **Create stack** and in the dropdown choose **With new resources (standard)**. 7. In the **Template source** field select **Upload a template file**, choose the `GitLabElasticScalingRunner.cf.yml` file you have just downloaded above, and choose **Next**. 8. In the **Stack name** field enter `linux-docker-scaling-spotonly` (**extremely important**, as this name is used in the IAM policy above). -Investigate the parameters presented and try deploying the stack yourself. Expand the section below to see step-by-step instructions. - -{{%expand "Click to reveal detailed instructions" %}} +**Challenge:** Investigate the parameters presented and try deploying the stack yourself. Expand the section below to see step-by-step instructions. +{{%expand "Click to reveal the instructions" %}} 9. In the **GitLab Instance URL** field enter GitLab URL you saved previously (in the format `https://xxx.cloudfront.net`). 10. In the **One or more runner Registration tokens from the target instance.** field enter the token you saved previously. 11. In the **The S3 bucket that will be used for a shared runner cache.** leave the default value (do not enter the GitLabCacheBucket value you saved from CloudFormation Output values, as at the moment the template will still try to create policies using the custom bucket and will fail if a different one is provided). 12. In the **The number of instances that should be configured. Generally 1 for warm HA and 2 for hot HA.** enter `2`. -13. In the **Override automatic IAM Instance Profile for a precreated one.** type `GitLabRunner`. -14. In the **The VPC in the account and region should be used.** enter the VPC ID you saved from CloudFormation Output values in [**Workshop Preparation**](/amazon-ec2-spot-cicd-workshop/gitlab-spot/prep.html) (in the format `vpc-...`). -15. In the field **Second priority instance type to be used - if previous priorities are exhausted. Used for Ec2 Fleet when not using spot.** enter `m5d.large`. For the third and fourth priority enter `m5n.large` and `c5.large` respectively. +13. In the **Override automatic IAM Instance Profile for a precreated one.** type `gitlab-runner`. +14. In the **The VPC in the account and region should be used**, get the VPC ID by running below command in Cloud9: +``` +echo VPC ID = $VPC +``` +15. In the field **Second priority instance type to be used - if previous priorities are exhausted. Used for Ec2 Fleet when not using spot.** enter `m5a.large`. For the third and fourth priority enter `m5d.large` and `m5n.large` respectively. 16. In the field **Whether to AutoScale the Scaling Group.** select `true` in the dropdown. 17. In the field **Maximum instances in the Scaling Group.** type `10`. 18. In the field **Scale in threshold (percent).** type `40`. @@ -173,14 +215,14 @@ Investigate the parameters presented and try deploying the stack yourself. Expan {{% /expand%}} {{% notice tip %}} -You had to use the full template to customize the IAM role used by the runners. If your production scenario does not require this and you are fine with the default permissions, you can use one of the easy buttons (out-of-the-box scenarios) provided at https://gitlab.com/guided-explorations/aws/gitlab-runner-autoscaling-aws-asg#easy-buttons-provided to deploy the stack: this will require less parameters to customize. +You had to use the full template to customize the IAM role used by the runners. If your production scenario does not require this and you are fine with the default permissions, you can use one of the easy buttons (out-of-the-box scenarios) provided [**here**](https://gitlab.com/guided-explorations/aws/gitlab-runner-autoscaling-aws-asg#easy-buttons-provided) to deploy the stack: this will require less parameters to customize. {{% /notice %}} -Now you can open the EC2 console and verify that your runner(s) are using spot instances: open the corresponding EC2 instance (its name starts with `linux-docker-scaling-spotonly-`) and check the **Lifecycle** field: +25. Now you can open the EC2 console and verify that your runner(s) are using spot instances: open the corresponding EC2 instance (its name starts with `linux-docker-scaling-spotonly-`) and check the **Lifecycle** field: ![EC2 Console Screenshot: Runner lifecycle](/images/gitlab-spot/AWSConsole-EC2RunnerLifecycle.png) -25. Return to the browser tab with GitLab, refresh the CI/CD settings page and make sure that your runner(s) have appeared in the **Runners** section: +26. Return to the browser tab with GitLab, refresh the CI/CD settings page and make sure that your runner(s) have appeared in the **Runners** section: ![GitLab Screenshot: Runner available](/images/gitlab-spot/GitLab-RunnerAvailable.png) diff --git a/content/amazon-ec2-spot-cicd-workshop/gitlab-spot/lab3.md b/content/amazon-ec2-spot-cicd-workshop/gitlab-spot/040-building-demo-app.md similarity index 96% rename from content/amazon-ec2-spot-cicd-workshop/gitlab-spot/lab3.md rename to content/amazon-ec2-spot-cicd-workshop/gitlab-spot/040-building-demo-app.md index 347ea914..d5c32d27 100644 --- a/content/amazon-ec2-spot-cicd-workshop/gitlab-spot/lab3.md +++ b/content/amazon-ec2-spot-cicd-workshop/gitlab-spot/040-building-demo-app.md @@ -1,11 +1,10 @@ +++ title = "Building the demo app" -weight = 50 +weight = 40 +++ In this lab you will push the changes to your origin repository and verify that the pipeline has successfully finished both in GitLab and by checking the image in Amazon ECR. -{{%expand "Click to reveal detailed instructions" %}} 1. Return to the browser tab with Cloud9 and execute the following command in the terminal. Specify `root` as the username and the same password you used in [**Create a GitLab repository**](lab1.html) to log in to GitLab: ``` @@ -23,8 +22,6 @@ git push -u origin main ![ECR Console Screenshot: Images](/images/gitlab-spot/AWSConsole-ECRImages.png) -{{% /expand%}} - You have successfully built the image and can now proceed to [**Deploying Amazon EKS on Spot instances**](lab4.html). ### Challenges diff --git a/content/amazon-ec2-spot-cicd-workshop/gitlab-spot/lab4.md b/content/amazon-ec2-spot-cicd-workshop/gitlab-spot/050-deploying-eks-on-spot.md similarity index 87% rename from content/amazon-ec2-spot-cicd-workshop/gitlab-spot/lab4.md rename to content/amazon-ec2-spot-cicd-workshop/gitlab-spot/050-deploying-eks-on-spot.md index 8eaf013f..f1600332 100644 --- a/content/amazon-ec2-spot-cicd-workshop/gitlab-spot/lab4.md +++ b/content/amazon-ec2-spot-cicd-workshop/gitlab-spot/050-deploying-eks-on-spot.md @@ -7,17 +7,15 @@ You will now deploy an Amazon EKS cluster in order to roll out your newly built The Terraform files are located in `~/environment/amazon-ec2-spot-cicd-workshop/gitlab-spot/eks-cluster` directory of your Cloud9 environment. -{{%expand "Click to reveal detailed instructions" %}} 1. Return to the browser tab with Cloud9 and execute the following commands in the terminal to download and install `kubectl` that you will be using to work with the Kubernetes cluster: - ``` cd ~/environment -sudo curl -sLo /usr/local/bin/kubectl "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl" +export KUBECTL_VERSION=v1.22.10 +sudo curl --silent --location -o /usr/local/bin/kubectl https://storage.googleapis.com/kubernetes-release/release/${KUBECTL_VERSION}/bin/linux/amd64/kubectl sudo chmod +x /usr/local/bin/kubectl ``` 2. Switch to the directory with IaC templates, initialize the Terraform working directory, and apply the changes: - ``` cd ~/environment/amazon-ec2-spot-cicd-workshop/gitlab-spot/eks-cluster terraform init @@ -29,26 +27,26 @@ terraform apply ``` 3. When asked for the parameters, enter the following values: - * **kubernetes_version**: the latest version of Kubernetes that you can find in [Amazon EKS documentation](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html): only major and minor version separated with a dot without patch release, for example, `1.23` - * **vpc_id**: the VPC ID you saved from CloudFormation Output values in [**Workshop Preparation**](/amazon-ec2-spot-cicd-workshop/gitlab-spot/prep.html) in the format `vpc-...` + * **kubernetes_version**: enter `1.22` + * **vpc_id**: open a new terminal in Cloud9 and run below command to get the VPC ID + ``` + echo VPC ID = $VPC + ``` ![Cloud9 Console Screenshot: Terraform variables](/images/gitlab-spot/Cloud9-TerraformVars.png) 4. When asked if you want to perform the changes, check the list of resources to be created, type `yes`, and press Enter. It should take approximately 15 minutes to deploy the cluster. 5. After the process has finished, execute the following command to update the `kubeconfig`, using the information from Amazon EKS: - ``` aws eks update-kubeconfig --region $TF_VAR_aws_region --name gitlab-spot-workshop ``` 6. Execute the below commands to verify that you can reach Kubernetes API. The first should return all Kubernetes resources across the namespaces and the second should show 3 worker nodes: - ``` kubectl get all -A kubectl get nodes ``` 7. Execute the below command to install AWS Load Balancer Controller (it will be used to configure Application Load Balancer for your pods): - ``` curl -sSL https://raw.githubusercontent.com/helm/helm/master/scripts/get-helm-3 | bash helm repo add eks https://aws.github.io/eks-charts @@ -61,27 +59,22 @@ helm install aws-load-balancer-controller eks/aws-load-balancer-controller --set ![EC2 Console Screenshot: Instance list with instance lifecycle](/images/gitlab-spot/AWSConsole-EC2InstancesLifecycle.png) -{{% /expand%}} - ### Add GitLab role to Kubernetes RBAC By default, the IAM user or role that created Amazon EKS cluster gets access to its Kubernetes API. However, as you have different roles assigned to the Cloud9 environment and the GitLab runners, you need to add the latter to Kubernetes Role Based Access Control (RBAC). You will do it by manually modifying Kubernetes ConfigMap called `aws-auth`. You could have done it directly in Terraform, but in this workshop we suggest that you do it manually to better understand the concepts. -{{%expand "Click to reveal detailed instructions" %}} 1. Return to the browser tab with Cloud9 and in the terminal execute the following command, which will save the ConfigMap current manifest into `aws-auth.yaml` file: - ``` cd ~/environment kubectl get configmap -n kube-system aws-auth -o yaml > aws-auth.yaml ``` 2. To generate the lines that you will add into the file, execute the following commands: - ``` export ACCOUNT_ID=$(aws sts get-caller-identity --output text --query Account) cat << EoF - - rolearn: arn:aws:iam::${ACCOUNT_ID}:role/GitLabRunner + - rolearn: arn:aws:iam::${ACCOUNT_ID}:role/gitlab-runner groups: - system:masters username: gitlab-runner @@ -99,8 +92,6 @@ EoF kubectl apply -f aws-auth.yaml ``` -{{% /expand%}} - You are now ready for the final steps to deploy your demo application into the cluster in [**Installing the demo app into Amazon EKS**](lab5.html). ### Challenge diff --git a/content/amazon-ec2-spot-cicd-workshop/gitlab-spot/lab5.md b/content/amazon-ec2-spot-cicd-workshop/gitlab-spot/060-deploy-app-to-eks.md similarity index 89% rename from content/amazon-ec2-spot-cicd-workshop/gitlab-spot/lab5.md rename to content/amazon-ec2-spot-cicd-workshop/gitlab-spot/060-deploy-app-to-eks.md index 2b970498..da9d282c 100644 --- a/content/amazon-ec2-spot-cicd-workshop/gitlab-spot/lab5.md +++ b/content/amazon-ec2-spot-cicd-workshop/gitlab-spot/060-deploy-app-to-eks.md @@ -1,14 +1,13 @@ +++ title = "Installing the demo app into Amazon EKS" -weight = 50 +weight = 60 +++ In this section you will deploy the demo application you built earlier in the new Amazon EKS cluster deployed fully on spot instances. -{{%expand "Click to reveal detailed instructions" %}} 1. In the Cloud9 file tree on the left open file `amazon-ec2-spot-cicd-workshop/gitlab-spot/demo-app/.gitlab-ci.yml` (if you don't see it, make sure you have enabled the hidden files in [**Workshop Preparation**](prep.html)). -2. Change the jobs `deploy_to_eks` and `test_on_eks` to the following ones: +2. Change the jobs `deploy_to_eks` and `test_on_eks` to the following ones: ``` deploy_to_eks: stage: deploy @@ -16,8 +15,9 @@ deploy_to_eks: before_script: - aws --version - aws eks update-kubeconfig --region $REGION --name $K8S_CLUSTER_NAME - - apt-get install -y gettext # To get envsubst - - curl -sLo /usr/local/bin/kubectl "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl" + - apt-get install -y gettext # To get envsubst + - export KUBECTL_VERSION=v1.22.10 + - curl --silent --location -o /usr/local/bin/kubectl https://storage.googleapis.com/kubernetes-release/release/${KUBECTL_VERSION}/bin/linux/amd64/kubectl - chmod +x /usr/local/bin/kubectl script: - envsubst < k8s_deploy.yaml > k8s_deploy_filled.yaml @@ -78,13 +78,9 @@ test_on_eks: - deploy_to_eks ``` -The file should look similar to the below screenshot: - -![Cloud9 Console Screenshot: GitLab CI/CD scripts](/images/gitlab-spot/Cloud9-GitLabCI.png) - 3. Save the file, using **Ctrl + S** or **Cmd + S** depending on your Operating System, or choosing **File** > **Save**. Then close it. -4. Create a new commit with the updated file and push it to the origin: +4. Create a new commit with the updated file and push it to the origin: ``` cd ~/environment/amazon-ec2-spot-cicd-workshop/gitlab-spot/demo-app/ git add .gitlab-ci.yml @@ -93,22 +89,20 @@ git push ``` 5. Return to the browser tab with GitLab and in the navigation pane choose **CI/CD** > **Pipelines**. + 6. Make sure that the CI/CD pipeline is successfully completed or wait until it does. -7. You can click on the circle to see the job output. For example, for the right-most one it would show the testing result: +7. You can click on the circle to see the job output. For example, for the right-most one it would show the testing result: ![GitLab Screenshot: GitLab Testing Job output](/images/gitlab-spot/GitLab-TestingJob.png) 8. Return to the Cloud9 tab and print the information about the new service: - ``` echo http://$(kubectl get ingress spot-demo -o jsonpath='{.status.loadBalancer.ingress[*].hostname}')/info/ ``` -8. Open the output URL in a new browser tab and refresh the page several times to make sure that the requests reach pods on different worker nodes, all on spot instances: - +9. Open the output URL in a new browser tab and refresh the page several times to make sure that the requests reach pods on different worker nodes, all on spot instances: ![Demo App Screenshot](/images/gitlab-spot/DemoApp.png) -{{% /expand%}} You have deployed the demo application in Kubernetes cluster (created in Amazon EKS service) with all its worker nodes running on Amazon EC2 Spot instances. It is useful for executing tests in your CI/CD pipeline (though AWS customers run full Production clusters on spot instances too): for example, you can add new spot nodes into your cluster right from the pipeline and after finishing testing remove them. diff --git a/content/amazon-ec2-spot-cicd-workshop/gitlab-spot/cleanup.md b/content/amazon-ec2-spot-cicd-workshop/gitlab-spot/070-cleanup.md similarity index 99% rename from content/amazon-ec2-spot-cicd-workshop/gitlab-spot/cleanup.md rename to content/amazon-ec2-spot-cicd-workshop/gitlab-spot/070-cleanup.md index a844b8c0..c76f121d 100644 --- a/content/amazon-ec2-spot-cicd-workshop/gitlab-spot/cleanup.md +++ b/content/amazon-ec2-spot-cicd-workshop/gitlab-spot/070-cleanup.md @@ -1,6 +1,6 @@ +++ title = "Workshop Cleanup" -weight = 60 +weight = 70 +++ You will now remove the resources created during the workshop. diff --git a/content/amazon-ec2-spot-cicd-workshop/gitlab-spot/before/self_paced.md b/content/amazon-ec2-spot-cicd-workshop/gitlab-spot/before/self_paced.md index 0cc6e41d..cc8128b6 100644 --- a/content/amazon-ec2-spot-cicd-workshop/gitlab-spot/before/self_paced.md +++ b/content/amazon-ec2-spot-cicd-workshop/gitlab-spot/before/self_paced.md @@ -15,7 +15,6 @@ Your account must have the ability to create new IAM roles and scope other IAM p 1. If you don't already have an AWS account with Administrator access: [create one now by clicking here](https://aws.amazon.com/getting-started/) 2. Log in to [AWS Console](https://console.aws.amazon.com/) with an IAM user having administrator permissions. -3. Download the CloudFormation YAML-template from [this link](https://raw.githubusercontent.com/awslabs/ec2-spot-workshops/master/workshops/amazon-ec2-spot-cicd-workshop/gitlab-spot/gitlab-deploy.yml). ### Create an SSH key @@ -31,13 +30,14 @@ You don't need the key to complete the labs, but it is still configured when cre * Save the .pem file as suggested by your browser ### Deploy GitLab -Now you will deploy a GitLab instance without any runners. As it is not the purpose of this workshop to dive deep into GitLab itself, the deployment will be fully automated using Infrastructure as Code template in AWS CloudFormation. It will deploy a VPC with two public subnets, an Amazon S3 bucket that you can configure as GitLab cache, an EC2 instance with GitLab itself, an Application Load Balancer and an Amazon CloudFront distribution to organize a secure access to it, an Amazon ECR repository for storing the container image, and a number of supplementary resources. +Now you will deploy a GitLab without any runners. As it is not the purpose of this workshop to dive deep into GitLab itself, the deployment will be fully automated using Infrastructure as Code template in AWS CloudFormation. It will deploy a VPC with two public subnets, an Amazon S3 bucket that you can configure as GitLab cache, an EC2 Auto Scaling group for GitLab, an Application Load Balancer and an Amazon CloudFront distribution to organize a secure access to it, an Amazon ECR repository for storing the container image, and a number of supplementary resources. 1. Open **CloudFormation** service in the AWS Console. 2. In the navigation pane choose **Stacks**. 3. Choose **Create stack** and in the dropdown choose **With new resources (standard)**. -4. In the **Template source** field select **Upload a template file**, choose the file you saved in the [**Preparation**](#preparation) section above, and choose **Next**. -5. In the **Stack name** field enter `mod-gitlab-spot-workshop`, in the **EEKeyPair** field select `ee-default-key-pair` or the name of the key you used in the steps above. Leave the default values in other fields and choose **Next**. -6. Choose **Next**. -7. Mark the checkbox **I acknowledge that AWS CloudFormation might create IAM resources.** and choose **Create stack**. -8. Wait until the stack is in `CREATE_COMPLETE` status (it should take approximately 15 minutes) and continue with [**Workshop Preparation**](/amazon-ec2-spot-cicd-workshop/gitlab-spot/prep.html). \ No newline at end of file +4. Download the CloudFormation YAML-template from [this link](https://raw.githubusercontent.com/awslabs/ec2-spot-workshops/master/workshops/amazon-ec2-spot-cicd-workshop/gitlab-spot/gitlab-deploy.yml). +5. In the **Template source** field select **Upload a template file**, choose the file you saved in the step above, and choose **Next**. +6. In the **Stack name** field enter `mod-gitlab-spot-workshop`, in the **EEKeyPair** field select `ee-default-key-pair` or the name of the key you used in the steps above. Leave the default values in other fields and choose **Next**. +7. Choose **Next**. +8. Mark the checkbox **I acknowledge that AWS CloudFormation might create IAM resources.** and choose **Create stack**. +9. Wait until the stack is in `CREATE_COMPLETE` status (it should take approximately 15 minutes) and continue with [**Workshop Preparation**](/amazon-ec2-spot-cicd-workshop/gitlab-spot/prep.html). \ No newline at end of file diff --git a/workshops/amazon-ec2-spot-cicd-workshop/gitlab-spot/gitlab-deploy.yml b/workshops/amazon-ec2-spot-cicd-workshop/gitlab-spot/gitlab-deploy.yml index 20e38bd4..3d13bff4 100644 --- a/workshops/amazon-ec2-spot-cicd-workshop/gitlab-spot/gitlab-deploy.yml +++ b/workshops/amazon-ec2-spot-cicd-workshop/gitlab-spot/gitlab-deploy.yml @@ -606,6 +606,11 @@ Resources: - cp -ar /home/ec2-user/environment/spot-workshop/workshops/amazon-ec2-spot-cicd-workshop/ /home/ec2-user/environment/ - rm -rf /home/ec2-user/environment/spot-workshop/ - chown -R ec2-user:ec2-user /home/ec2-user/environment/amazon-ec2-spot-cicd-workshop/ + - curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "/home/ec2-user/environment/awscliv2.zip" + - cd /home/ec2-user/environment + - unzip awscliv2.zip + - sudo ./aws/install + - sudo yum -y install jq - echo "Bootstrap completed with return code $?" Tags: - Key: Project