- \n
- CI CD Docker Tool Stack<\/span><\/a><\/li>\n
- Architecture<\/span><\/a><\/li>\n
- CI CD workflow and phases<\/span><\/a><\/li>\n
- Deployment strategy<\/span><\/a><\/li>\n
- Dockerize Node.js app<\/span><\/a><\/li>\n
- Setup Github Repositories<\/span><\/a><\/li>\n
- Setup the AWS Infrastructure<\/span><\/a><\/li>\n
- Setup Jenkins on the EC2 Instance<\/span><\/a><\/li>\n
- Configure the Jenkins Server<\/span><\/a><\/li>\n
- Deploy the Nodejs Application to the ECS Cluster<\/span><\/a><\/li>\n
- Cleanup the resources we created<\/span><\/a><\/li>\n
- Summary<\/span><\/a><\/li>\n
- Conclusion<\/span><\/a><\/li>\n
- FAQs<\/span><\/a><\/li>\n<\/ul>\n
A CI CD Pipeline or Continuous Integration Continuous Delivery Pipeline is a set of instructions to automate the process of Software tests, builds, and deployments. Here are a few benefits of implementing CI CD in your organization.<\/p>\n
- \n
- Smaller Code Change<\/strong>
\nThe ability of CI CD Pipelines to allow the integration of a small piece of code at a time helps developers to recognize any potential problem before too much work is completed.<\/li>\n- Faster Delivery<\/strong>
\nMultiple daily releases or continual releases can be made a reality using CI CD Pipelines.<\/li>\n- Observability<\/strong>
\nHaving automation in place that generates extensive logs in each stage of the development process helps to understand if something goes wrong.<\/li>\n- Easier Rollbacks<\/strong>
\nThere are chances that the code that has been deployed may have issues. In such cases, it is very crucial to get back to the previous working release as soon as possible. One of the biggest advantages of using the CI CD Pipelines is that you can quickly and easily roll back to the previous working release.<\/li>\n- Reduce Costs
\n<\/strong>Having automation in place for repetitive tasks frees up the Developer and Operation guys\u2019 time that could be spent on Product Development.<\/li>\n<\/ol>\nThese are just a few benefits of having CI CD Pipelines for builds and deployments. On this video you can continue learning the CI CD benefits and why use a CI CD in place.<\/p>\n
Now, before we proceed with the steps to set up a CI CD Pipeline with Jenkins, Containers, and Amazon ECS, let\u2019s see in short what tools and technologies we will be using.<\/p>\n
CI CD Docker Tool Stack<\/h2>\n
- \n
- Github
\n<\/strong>It is a web-based application or a cloud-based service where people or developers collaborate, store and manage their application code using Git. We will create and store our sample Nodejs application code here.<\/li>\n<\/ol>\n\u00a0<\/div>\n- \n
- AWS EC2 Instance
\n<\/strong>AWS EC2 is an Elastic Computer Service provided by Amazon Web Services used to create Virtual Machines or Virtual Instances on AWS Cloud. We will create an EC2 instance and install Jenkins and other dependencies in it.<\/li>\n<\/ol>\n\u00a0<\/div>\n- \n
- Java
\n<\/strong>This will be required to run Jenkins Server.<\/li>\n<\/ol>\n\u00a0<\/div>\n- \n
- AWS CLI
\n<\/strong>aws-cli i.e AWS Command Line Interface is a command-line tool used to manage AWS Services using commands. We will be using it to manage AWS ECS Task and ECS Service.<\/li>\n<\/ol>\n\u00a0<\/div>\n- \n
- Nodejs and Npm
\n<\/strong>Nodejs is a back-end JavaScript runtime environment and Npm is a package manager for Node. We will be creating a CI CD Docker Pipeline for the Nodejs application.<\/li>\n<\/ol>\n\u00a0<\/div>\n- \n
- Docker
\n<\/strong>Docker is an open-source containerization platform used for developing, shipping, and running applications. We will use it to build Docker Images of our sample Nodejs application and push\/pull them to\/from AWS ECR.
\n<\/strong><\/li>\n<\/ol>\n\u00a0<\/div>\n- \n
- Jenkins
\n<\/strong>Jenkins is an open-source, freely available automation server used to build, test, and deploy software applications. We will be creating our CI CD Docker Pipeline to build, test and deploy our Nodejs application on AWS ECS using Jenkins<\/li>\n<\/ol>\n\u00a0<\/div>\n- \n
- AWS ECR
\n<\/strong>AWS Elastic Container Registry is a Docker Image Repository fully managed by AWS to easily store, share, and deploy container images. We will be using AWS ECR to store Docker Images of our sample Nodejs application.<\/li>\n<\/ol>\n\u00a0<\/div>\n- \n
- AWS ECS
\n<\/strong>AWS Elastic Container Service is a container orchestration service fully managed by AWS to easily deploy, manage, and scale containerized applications. We will be using it to host our sample Nodejs application.<\/li>\n<\/ol>\nArchitecture<\/h2>\n
After the CI CD Docker Pipeline is successfully set up, we will push commits to our Github repository and in turn, Github Webhook will trigger the CI CD Pipeline on Jenkins Server. Jenkins Server will then pull the latest code, carry out unit tests, build a docker image and push it to AWS ECR. After the image is pushed to AWS ECR, the same image will be deployed in AWS ECS by Jenkins.<\/p>\n
CI CD workflow and phases<\/h2>\n
Workflow<\/h3>\n
CI and CD Workflow allows us to focus on Development while it carries out the tests, build, and deployments in an automated way.\u00a0<\/p>\n
- \n
- Continuous Integration<\/strong>
\nThis allows the developers to push the code to the Version Control System or\u00a0 Source Code Management System, build & test the latest code pushed by the developer and generate & store artifacts.<\/li>\n- Continuous Delivery<\/strong>
\nThis is the process that lets us deploy the tested code to the Production whenever required.\u00a0<\/li>\n- Continuous Deployment
\n<\/strong>This goes one step further and releases every single change without any manual intervention to the customer system every time the production pipeline passes all the tests.\u00a0<\/li>\n<\/ol>\n\u00a0<\/div>\nPhases<\/h3>\n
The primary goal of the automated CI CD pipeline is to build the latest code and deploy it. There can be various stages as per the need. The most common ones are mentioned below.<\/p>\n
- \n
- Trigger
\n<\/strong>The CI CD pipeline can do its job on the specified schedule when executed manually or triggered automatically on a particular action in the Code Repository.\u00a0\u00a0\u00a0<\/li>\n- Code Pull<\/strong>
\nIn this phase, the pipeline pulls the latest code whenever the pipeline is triggered.<\/li>\n- Unit Tests<\/strong>
\nIn this phase, the pipeline performs tests that are there in the codebase, this is also referred to as unit tests.<\/li>\n- Build or Package<\/strong>
\nOnce all the tests pass, the pipeline moves forward and builds artifacts or docker images in case of dockerized applications.<\/li>\n- Push or Store<\/strong>
\nIn this phase, the code that has been built is pushed to the Artifactory or Docker Repository in case of dockerized applications.<\/li>\n- Acceptance Tests
\n<\/strong>This phase or stage of the pipeline validates if the software behaves as intended. It is a way to ensure if the software or application does what it is meant to do.<\/li>\n- Deploy
\n<\/strong>This is the final stage in any CI CD pipeline. In this stage, the application is ready for delivery or deployment.<\/li>\n<\/ol>\nDeployment strategy<\/h2>\n
A deployment strategy is a way in which containers of the micro-services are taken down and added. There are various options available; however, we will only discuss the ones that are available and supported by ECS<\/p>\n
Rolling updates<\/h3>\n
In rolling updates, the scheduler in the ECS Service replaces the currently running tasks with new ones. The tasks in the ECS cluster are nothing but running containers created out of the task definition. Deployment configuration controls the number of tasks that Amazon ECS adds or removes from the service. The lower and the upper limit on the number of tasks that should be running is controlled by minimumHealthyPercent and maximumPercent respectively.\u00a0<\/p>\n
- \n
- minimumHealthyPercent example<\/strong>: If the value of\u00a0minimumHealthyPercent<\/strong>\u00a0is 50 and the desired task count is 4, then the scheduler can stop 2 existing tasks before starting 2 new tasks<\/li>\n
- maximumPercent example<\/strong>: If the value of\u00a0maximumPercent<\/strong>\u00a0is 4 and the desired task is 4 then the scheduler can start 4 new tasks before stopping 4 existing tasks.<\/li>\n<\/ol>\n
\u00a0<\/p>\n
If you want to learn more about this, visit the official documentation\u00a0here<\/a>.<\/p>\n
\u00a0<\/div>\nBlue\/Green Deployment<\/h3>\n
Blue\/Green deployment strategy enables the developer\u00a0 to verify a new deployment before sending traffic to it by installing an updated version of the application as a new replacement task set.<\/p>\n
There are primarily 3 ways in which traffic can shift during blue\/green deployment.<\/p>\n
- \n
- Canary<\/strong>\u00a0\u2014 Tra\ufb03c is shifted in two increments, percentage of tra\ufb03c shifted to your updated task set in the \ufb01rst increment and the interval, in minutes, before the remaining tra\ufb03c is shifted in the second increment.<\/li>\n
- Linear<\/strong>\u00a0\u2014 Tra\ufb03c is shifted in equal increments, the percentage of tra\ufb03c shifted in each increment and the number of minutes between each increment.<\/li>\n
- All-at-once<\/strong>\u00a0\u2014 All tra\ufb03c is shifted from the original task set to the updated task set all at once.<\/li>\n<\/ol>\n
To learn more about this, visit the official documentation\u00a0here<\/a>.<\/p>\n
Out of these 2 strategies, we will be using the rolling-updates deployment strategy in our demo application.<\/p>\n
Dockerize Node.js app<\/h2>\n
Now, let\u2019s get started and make our hands dirty.<\/p>\n
The Dockerfile for the sample Nodejs application is as follows. There is no need to copy-paste this file, it is already available in the sample git repository that you cloned previously.<\/p>\n
Let\u2019s just try to understand the instructions of our Dockerfile.<\/p>\n
- \n
- FROM node:12.18.4-alpine
\nThis will be our base image for the container.<\/li>\n - WORKDIR \/app
\nThis will be set as a working directory in the container.<\/li>\n - ENV PATH \/app\/node_modules\/.bin:$PATH
\nPATH variable is assigned a path to \/app\/node_modules\/.bin.<\/li>\n - COPY package.json .\/
\nPackage.json will be copied in the working directory of the container.<\/li>\n - RUN npm install
\nInstall dependencies.<\/li>\n - COPY . .\/
\nCopy files and folders with dependencies from the host machine to the container.<\/li>\n - EXPOSE 3000
\nAllow to port 300 of the container.<\/li>\n - CMD [\u201cnode\u201d, \u201c.\/src\/server.js\u201d]
\nStart the application<\/li>\n<\/ol>\n\u00a0<\/p>\n
This is the Docker file that we will use to create a docker image.<\/p>\n
\u00a0<\/div>\nSetup Github Repositories<\/h2>\n
Create a new repository<\/h3>\n
- \n
- Go to\u00a0https:\/\/github.com\/<\/a>, create an account if you don\u2019t have it already else log in to your account and create a new repository. You can name it as per your choice; however, I would recommend using the same name to avoid any confusion.
<\/li>\n<\/ol>\n
\u00a0<\/div>\n- \n
- You will get the screen as follows, copy the repository URL and keep it handy. Call this URL as a Github Repository URL and note it down in the text file on your system.\u00a0
<\/li>\n<\/ol>\n
Note<\/strong>: Create a new text file on your system and note down all the details that will be required later.<\/p>\n
\u00a0<\/div>\nCreate a Github Token<\/h3>\n
This will be required for authentication purposes. It will be used instead of a password for Git over HTTPs, or can be used to authenticate to the API over Basic Authentication.<\/p>\n
- \n
- Click on the user icon in the top-right, go to \u201cSettings\u201d, then click on the \u201cDevelopers settings\u201d option in the left panel.
<\/li>\n<\/ol>\n
\u00a0<\/div>\n- \n
- Click on the\u00a0 \u201cPersonal access tokens\u201d options and \u201cGenerate new token\u201d to create a new token.
\n<\/li>\n<\/ol>\n
\u00a0<\/div>\n- \n
- Tick the \u201crepo\u201d checkbox, the token will then have \u201cfull control of private repositories\u201d
<\/li>\n<\/ol>\n
\u00a0<\/div>\n- \n
- You should see your token created now.
<\/li>\n<\/ol>\n
\u00a0<\/div>\nClone the sample Repository<\/h3>\n
- \n
- Check your present working directory.
\npwd<\/li>\n<\/ol>\n\u00a0<\/p>\n
Note:<\/strong>\u00a0You are in the home directory, i.e. \/home\/ubuntu.<\/p>\n
- \n
- Clone my sample repository containing all the required code.
\ngit clone\u00a0https:\/\/github.com\/shivalkarrahul\/nodejs.git<\/a><\/li>\n- Create a new repository. This repository will be used for CI CD Pipeline setup.
\ngit clone\u00a0https:\/\/github.com\/shivalkarrahul\/demo-nodejs-app.git<\/a><\/li>\n- Copy all the code from my\u00a0nodejs<\/a>\u00a0repository to the newly created\u00a0demo-nodejs-app<\/a>\u00a0repository.
\ncp -r nodejs\/* demo-nodejs-app\/<\/li>\n- Change your working directory.
\ncd demo-nodejs-app\/<\/li>\n<\/ol>\n\u00a0<\/p>\n
Note:<\/strong>\u00a0For the rest of the article, do not change your directory. Stay in the same directory, here it is \/home\/ubuntu\/demo-nodejs-app\/, and execute all the commands from there.\u00a0<\/p>\n
- \n
- ls -l<\/li>\n
- git status<\/li>\n<\/ol>\n\u00a0<\/div>\n
<\/p>\n
\u00a0<\/div>\nPush your first commit to the repository<\/h3>\n
- \n
- Check your present working directory, it should be the same. Here it is \/home\/ubuntu\/demo-nodejs-app\/
\npwd<\/li>\n - Set a username for your git commit message.
\ngit config user.name \u201cRahul\u201d<\/li>\n - Set an email for your git commit message.
\ngit config user.email \u201c<test@email.com<\/a>>\u201d<\/li>\n- Verify the username and email you set.
\ngit config \u2013list<\/li>\n- Check the status, see files that have been changed or added to your git repository.
\ngit status<\/li>\n- Add files to the git staging area.
\ngit add<\/li>\n- Check the status, see files that have been added to the git staging area.
\ngit status<\/li>\n- Commit your files with a commit message.
\ngit commit -m \u201cMy first commit\u201d<\/li>\n- Push the commit to your remote git repository.
\ngit push<\/li>\n<\/ol>\n\u00a0<\/div>\n<\/p>\n
\u00a0<\/div>\nSetup the AWS Infrastructure<\/h2>\n
Create an IAM User with a Programmatic Access<\/h3>\n
- \n
- Create an IAM user with programmatic access in your AWS account and note down the access key and secret key in your text file for future references. Provide administrator permissions to the user.
\nWe don\u2019t need admin access; however, to avoid permission issues and for the sake of the demo, let\u2019s proceed with administrator access.<\/li>\n<\/ol>\n
\u00a0<\/div>\nCreate an ECR Repository<\/h3>\n
- \n
- Create an ECR Repository in your AWS account and note its URL in your text file for future references.<\/li>\n<\/ol>\n
<\/p>\n
\u00a0<\/div>\nCreate an ECS Cluster<\/h3>\n
- \n
- Go to ECS Console and click on \u201cGet Started\u201d to create a cluster.\u00a0
<\/li>\n<\/ol>\n
\u00a0<\/div>\n- \n
- Click on the \u201cConfigure\u201d button available in the \u201ccustom\u201d option under \u201cContainer definition\u201d.
<\/li>\n<\/ol>\n
\u00a0<\/div>\n- \n
- Specify a name to the container as \u201cnodejs-container\u201d, the ECR Repository URL in the \u201cImage\u201d text box, \u201c3000\u201d port in the Port mappings section, and then click on the \u201cUpdate\u201d button. You can specify any name of your choice for the container.
<\/li>\n<\/ol>\n
\u00a0<\/div>\n- \n
- You can now see the details you specified under \u201cContainer definition\u201d. Click on the \u201cNext\u201d button to proceed<\/li>\n<\/ol>\n
<\/p>\n
\u00a0<\/div>\n- \n
- Select \u201cApplication Load Balancer\u201d under \u201cDefine your service\u201d and then click on the \u201cNext\u201d button.<\/li>\n<\/ol>\n
<\/p>\n
\u00a0<\/div>\n- \n
- Keep the cluster name as \u201cdefault\u201d and proceed by clicking on the \u201cNext\u201d button. You can change the cluster name if you want.
<\/li>\n<\/ol>\n
\u00a0<\/div>\n- \n
- Review the configuration and it should look as follows. If the configurations match, then click on the \u201cCreate\u201d button. This will initiate the ECS Cluster creation.
<\/li>\n<\/ol>\n
\u00a0<\/div>\n- \n
- After a few minutes, you should have your ECS cluster created and the Launch Status should be something as follows.
<\/li>\n<\/ol>\n
\u00a0<\/div>\nCreate an EC2 Instance for setting up the Jenkins Server<\/h3>\n
- \n
- Create an EC2 Instance with Ubuntu 18.04 AMI and open its Port 22 for your IP and Port 8080 for 0.0.0.0\/0 in its Security Group. Port 22 will be required for ssh and 8080 for accessing the Jenkins Server. Port 8080 is where Github Webhook will try to connect to on Jenkins Server, hence we need to allow it for 0.0.0.0\/0<\/li>\n<\/ol>\n\u00a0<\/div>\n
Setup Jenkins on the EC2 Instance<\/h2>\n
After the instance is available, let\u2019s install Jenkins Server on it along with all the dependencies.<\/p>\n
Pre-requisites of the EC2 Instance<\/h3>\n
- \n
- Verify if the OS is Ubuntu 18.04 LTS
\ncat \/etc\/issue<\/li>\n<\/ol>\n- \n
- Check the RAM, minimum of 2 GB is what we require.
\nfree -m<\/li>\n<\/ol>\n- \n
- The User that you use to log in to the server should have sudo privileges. \u201cubuntu\u201d is the user available with sudo privileges for EC2 instances created using \u201cUbuntu 18.04 LTS\u201d AMI.
\nwhoami<\/li>\n - Check your present working directory, it will be your home directory.\u00a0
\npwd<\/li>\n<\/ol>\n<\/p>\n
\u00a0<\/div>\nInstall Java, JSON Processor jq, Nodejs\/NPM and aws-cli on the EC2 Instance<\/h3>\n
- \n
- Update your system by downloading package information from all configured sources.
\nsudo apt update<\/li>\n - Search and Install Java 11
\nsudo apt search openjdk
\nsudo apt install openjdk-11-jdk<\/li>\n - Install jq command, the JSON processor.
\nsudo apt\u00a0 install jq<\/li>\n - Install Nodejs 12 and NPM
\ncurl -sL\u00a0https:\/\/deb.nodesource.com\/setup_12.x<\/a>\u00a0| sudo -E bash \u2013
\nsudo apt install nodejs<\/li>\n- Install aws cli tool.
\nsudo apt\u00a0 install awscli<\/li>\n- Check the Java version.
\njava \u2013version<\/li>\n- Check the jq version.
\njq \u2013version<\/li>\n- Check the Nodejs version
\nnode \u2013version<\/li>\n- Check the NPM version
\nnpm \u2013version<\/li>\n- Check the aws cli version
\naws \u2013version<\/li>\n<\/ol>\n<\/figure>\n
Note: Make sure all your versions match the versions seen in the above image.\u00a0<\/p>\n
\u00a0<\/div>\nInstall Jenkins on the EC2 Instance<\/h3>\n
- \n
- Jenkins can be installed from the Debian repository
\nwget -q -O \u2013\u00a0http:\/\/pkg.jenkins-ci.org\/debian\/jenkins-ci.org.key<\/a>\u00a0| sudo apt-key add -sudo sh -c \u2018echo deb\u00a0http:\/\/pkg.jenkins-ci.org\/debian<\/a>\u00a0binary\/ > \/etc\/apt\/sources.list.d\/jenkins.list\u2019<\/li>\n- Update the apt package index
\nsudo apt-get update<\/li>\n- Install Jenkins on the machine
\nsudo apt-get install jenkins<\/li>\n- Check the service status if it is running or not.
\nservice jenkins status<\/li>\n- You should have your Jenkins up and running now. You may refer to the official documentation\u00a0here<\/a>\u00a0if you face any issues with the installation.\n
<\/li>\n<\/ol>\n
\u00a0<\/div>\nInstall Docker on the EC2 Instance<\/h3>\n
- \n
- Install packages to allow apt to use a repository over HTTPS:
\nsudo apt-get install apt-transport-https ca-certificates curl gnupg lsb-release<\/li>\n - Add Docker\u2019s official GPG key:
\ncurl -fsSL\u00a0https:\/\/download.docker.com\/linux\/ubuntu\/gpg<\/a>\u00a0| sudo gpg \u2013dearmor -o \/usr\/share\/keyrings\/docker-archive-keyring.gpg<\/li>\n- Set up the stable repository
\necho \u201cdeb [arch=amd64 signed-by=\/usr\/share\/keyrings\/docker-archive-keyring.gpg]\u00a0https:\/\/download.docker.com\/linux\/ubuntu<\/a>\u00a0 $(lsb_release -cs) stable\u201d | sudo tee \/etc\/apt\/sources.list.d\/docker.list > \/dev\/null<\/li>\n- Update the apt package index
\nsudo apt-get update<\/li>\n- Install the latest version of Docker Engine and containerd,
\nsudo apt-get install docker-ce docker-ce-cli containerd.io<\/li>\n- Check the docker version.
\ndocker \u2013version<\/li>\n- Create a \u201cdocker\u201d group, this may exit.
\nsudo groupadd docker<\/li>\n- Add \u201cubuntu\u201d user to the \u201cdocker\u201d group
\nsudo usermod -aG docker ubuntu<\/li>\n- Add \u201cjenkins\u201d user to the \u201cdocker\u201d group
\nsudo usermod -aG docker jenkins<\/li>\n- Test if you can create docker objects using \u201cubuntu\u201d user.
\ndocker run hello-world<\/li>\n- Switch to \u201croot\u201d user
\nsudo -i<\/li>\n- Switch to \u201cjenkins\u201d user
\nsu jenkins<\/li>\n- Test if you can create docker objects using \u201cjenkins\u201d user.
\ndocker run hello-world<\/li>\n- Exit from \u201cjenkins\u201d user
\nexit<\/li>\n- Exit from \u201croot\u201d user
\nexit<\/li>\n- Now you should be back in \u201cubuntu\u201d user. You may refer to the official documentation\u00a0here<\/a>\u00a0if you face any issues with the installation.
- Set up the stable repository
- Update the apt package index
- Install aws cli tool.
- Update your system by downloading package information from all configured sources.
- The User that you use to log in to the server should have sudo privileges. \u201cubuntu\u201d is the user available with sudo privileges for EC2 instances created using \u201cUbuntu 18.04 LTS\u201d AMI.
- Check the RAM, minimum of 2 GB is what we require.
- Verify if the OS is Ubuntu 18.04 LTS
- Create an EC2 Instance with Ubuntu 18.04 AMI and open its Port 22 for your IP and Port 8080 for 0.0.0.0\/0 in its Security Group. Port 22 will be required for ssh and 8080 for accessing the Jenkins Server. Port 8080 is where Github Webhook will try to connect to on Jenkins Server, hence we need to allow it for 0.0.0.0\/0<\/li>\n<\/ol>\n
- After a few minutes, you should have your ECS cluster created and the Launch Status should be something as follows.
- Review the configuration and it should look as follows. If the configurations match, then click on the \u201cCreate\u201d button. This will initiate the ECS Cluster creation.
- Keep the cluster name as \u201cdefault\u201d and proceed by clicking on the \u201cNext\u201d button. You can change the cluster name if you want.
- Select \u201cApplication Load Balancer\u201d under \u201cDefine your service\u201d and then click on the \u201cNext\u201d button.<\/li>\n<\/ol>\n
- You can now see the details you specified under \u201cContainer definition\u201d. Click on the \u201cNext\u201d button to proceed<\/li>\n<\/ol>\n
- Specify a name to the container as \u201cnodejs-container\u201d, the ECR Repository URL in the \u201cImage\u201d text box, \u201c3000\u201d port in the Port mappings section, and then click on the \u201cUpdate\u201d button. You can specify any name of your choice for the container.
- Click on the \u201cConfigure\u201d button available in the \u201ccustom\u201d option under \u201cContainer definition\u201d.
- Go to ECS Console and click on \u201cGet Started\u201d to create a cluster.\u00a0
- Create an ECR Repository in your AWS account and note its URL in your text file for future references.<\/li>\n<\/ol>\n
- Verify the username and email you set.
- Check your present working directory, it should be the same. Here it is \/home\/ubuntu\/demo-nodejs-app\/
- Create a new repository. This repository will be used for CI CD Pipeline setup.
- Clone my sample repository containing all the required code.
- Check your present working directory.
- You should see your token created now.
- Tick the \u201crepo\u201d checkbox, the token will then have \u201cfull control of private repositories\u201d
- Click on the\u00a0 \u201cPersonal access tokens\u201d options and \u201cGenerate new token\u201d to create a new token.
- Click on the user icon in the top-right, go to \u201cSettings\u201d, then click on the \u201cDevelopers settings\u201d option in the left panel.
- You will get the screen as follows, copy the repository URL and keep it handy. Call this URL as a Github Repository URL and note it down in the text file on your system.\u00a0
- Go to\u00a0https:\/\/github.com\/<\/a>, create an account if you don\u2019t have it already else log in to your account and create a new repository. You can name it as per your choice; however, I would recommend using the same name to avoid any confusion.
- Linear<\/strong>\u00a0\u2014 Tra\ufb03c is shifted in equal increments, the percentage of tra\ufb03c shifted in each increment and the number of minutes between each increment.<\/li>\n
- maximumPercent example<\/strong>: If the value of\u00a0maximumPercent<\/strong>\u00a0is 4 and the desired task is 4 then the scheduler can start 4 new tasks before stopping 4 existing tasks.<\/li>\n<\/ol>\n
- Code Pull<\/strong>
- Continuous Delivery<\/strong>
- Continuous Integration<\/strong>
- AWS ECS
- AWS ECR
- Jenkins
- Docker
- Nodejs and Npm
- AWS CLI
- Java
- AWS EC2 Instance
- Faster Delivery<\/strong>
- Architecture<\/span><\/a><\/li>\n