BitBucket CI/CD with AWS ECR and Kubernetes: Streamlining Your Node.js Development Process

BitBucket CI/CD with AWS ECR and Kubernetes: Streamlining Your Node.js Development Process

Continuous Integration and Continuous Deployment (CI/CD) practices have revolutionized software development by automating the build, test, and deployment processes. BitBucket and AWS ECR (Elastic Container Registry) are two popular tools that can be combined to create a robust CI/CD pipeline for Node.js applications. In this article, we will explore how to integrate BitBucket with AWS ECR, providing a step-by-step guide and a complete example in Node.js. We will also provide a working bitbucket-pipelines.yml file to help you get started quickly.

High Level CI/CD Plan:

Let's have a look at high level flow of CI/CD integration with Bitbucket, AWS, ECR and Kubernetes

• Create AWS ECR to hold the Docker image in the ECR registry.
• Create a bitbucket-pipelines.yml file to configure the CI/CD
• Configure the CI/CD along with the pipelines for branches
• Add the Steps for specific branches in the bitbucket-pipelines.yml file mainly for Build_Push and Prod_Deploy
• In the step Build_Push:
  • Configure AWS credentials for ECR access
  • Set environment variables for the application and AWS ECR repository
  • Log in to the AWS ECR repository using the AWS CLI
  • Build the Docker image
  • Push the Docker image to the ECR registry.
    
    (Build_Push step builds the Docker image, pushes it to the ECR registry, and saves relevant artifacts for further reference or deployment.)
    
    
• In the Step Prod_Deploy:
  • Downloads the kubectl binary, which is the command-line tool to interacting with Kubernetes clusters.
  • Copies the Kubernetes configuration file to the appropriate location.
  • Makes the kubectl binary executable.
  • Defines the image tag based on the BitBucket branch and commit.
  • Retrieves the available Kubernetes contexts.
  • Sets the Kubernetes context for the desired EKS cluster.
  • Applies the deployment configuration file to create the objects in the Kubernetes cluster.
    
    In this Prod_Deploy step: the code prepares the environment, retrieves the required tools, sets up authentication, updates the deployment configuration file, and deploys the application to the specified Kubernetes cluster using kubectl apply.
    
    
• Create .kube directory and write Kubernetes config file and the kube-prod-eks-deployment.yml deployment configuration file
• Define Kubernetes cluster, service objects in file kube-prod-eks-deployment.yml
• Configure BitBucket Repository Variables
• Enable pipeline from bitbucket
• Triggering the CI/CD Pipeline

Prerequisites

Before we begin, make sure you have the following in place:

(A). A BitBucket account with a repository containing your Node.js application code.

(B). An AWS account with ECR enabled.

Step 1: Setting up AWS ECR

AWS ECR (Elastic Container Registry) is a fully-managed container registry service provided by Amazon Web Services (AWS). It is used to store, manage, and deploy container images for applications running on container platforms like Docker and Kubernetes.

A. Log in to your AWS Management Console.

B. Navigate to the Elastic Container Registry (ECR) service.

Example image to create ECR repository

C. Create a new repository for your Node.js application by clicking on the "Create repository" button.

Example image of created ECR repository

D. Note down the repository URL as you will need it later.

Question: Is AWS ECR is orchestration tool?
Answer: No,

AWS ECR (Elastic Container Registry) is not an orchestration tool itself. AWS ECR is a container registry service. It provides a secure and private repository for your container images, ensuring that they are readily available for deployment on container platforms like Docker and Kubernetes.

On the other hand, orchestration tools, such as Kubernetes, Amazon Elastic Kubernetes Service (EKS), and Docker Swarm, focus on managing and coordinating the deployment, scaling, and networking of containers across multiple hosts or nodes. These tools handle tasks like container scheduling, load balancing, service discovery, and automatic scaling, providing a platform for managing containerized applications in a distributed environment.

While AWS ECR is not an orchestration tool, it is commonly used in conjunction with orchestration platforms like Kubernetes or ECS (Elastic Container Service) to store and manage container images that are then deployed and orchestrated using the respective tools. AWS ECR provides a reliable and scalable container image repository, while orchestration tools handle the runtime management and orchestration of containers based on those images.

Step 2: Configuring BitBucket Pipeline

A. In your BitBucket repository, create a new file called "bitbucket-pipelines.yml" in the root directory.

B. Open the file and add the following code:

C. Kubernetes configured (optional)

bitbucket-pipelines.yml

                                image:
                                    # pull the image to use in this pipeline
                                    name: 123456789012.dkr.ecr.ap-south-2.amazonaws.com/base/ps:idk-runners 
                                    aws:
                                    access-key: $AWS_ACCESS_KEY_ID
                                    secret-key: $AWS_SECRET_ACCESS_KEY
                                definitions:
                                    services:
                                        docker:
                                            memory: 3072
                                    caches:
                                        sonar: ~/.sonar/cache  # Caching SonarCloud artifacts will speed up your build
                    
                                    steps:
                    
                                        - step: &Snyk_Check
                                            name: 'Snyk'
                                            script:
                                            .
                                            .
                                            .
                    
                                        - step: &Sonar_Quality_Check
                                            name: 'Sonar Quality Check and Gate'
                                            .
                                            .
                                            .
                                    
                                        - step: &Git_Secrets_Scan
                                            name: 'Git Secrets Scan'
                                            .
                                            .
                                            .
                                    
                                        - step: &Test_case
                                            name: "Test case check"
                                            .
                                            .
                                            .
                                    
                                        - step: &Build_Push
                                            name: 'Build and Push'
                                            .
                                            .
                                            .
                                    
                                        - step: &Prod_Deploy
                                                name: 'prod-deploy'
                                                .
                                                .
                                                .
                                
                                pipelines:
                    
                                    branches:
                                    '**':
                                        - parallel:
                                            - step: *Sonar_Quality_Check
                                            - step: *Git_Secrets_Scan
                                            - step: *Snyk_Check
                                    master:
                                        - parallel:
                                            - step: *Git_Secrets_Scan
                                            - step: *Snyk_Check
                                        - step: *Test_case
                                        - step: *Build_Push
                                        - step: *Prod_Deploy
                              

Let's understand above codes:

---

image: -> name: 123456789012.dkr.ecr.123456789012.dkr.ecr.ap-south-2.amazonaws.com.amazonaws.com/base/ps:idk-runners

                                  image:
                                      name: 123456789012.dkr.ecr.ap-south-2.amazonaws.com/base/ps:idk-runners
                                      aws:
                                          access-key: $AWS_ACCESS_KEY_ID_EKS
                                          secret-key: $AWS_SECRET_ACCESS_KEY_EKS 
                              

The YAML snippet provided to define an image configuration for a container in a Kubernetes manifest or deployment file, along with AWS credentials for accessing the specified image repository.
* image: This specifies the image configuration for the container.
* name: This field defines the name of the container image.
* 123456789012.dkr.ecr.ap-south-2.amazonaws.com/base/ps:idk-runners: This is the fully qualified name of the container image. It follows the format "registry/repository/image:tag".

In this case:
* 123456789012.dkr.ecr.ap-south-2.amazonaws.com refers to the ECR (Elastic Container Registry) repository URL in the ap-south-2 AWS region.
* base/os is the repository and image name within the ECR repository.
* idk-runners is the tag assigned to the specific version or variant of the image.

This configuration specifies the container image that will be used for the deployment or pod in the Kubernetes cluster. The image name includes the registry URL, repository, image name, and tag. The Kubernetes cluster will pull this image from the specified ECR repository and run it as part of the deployment.
Note that this snippet is just a part of the overall Kubernetes manifest or deployment file, which likely contains additional configuration for the deployment, such as labels, ports, volumes, and more.

---

definitions->services->docker->memory

                                  definitions:
                                      services:
                                          docker:
                                              memory: 3072
                              

To define a memory limit for the Docker service within a configuration file.
* definitions: This section is used to define various configurations or settings.
* services: This subsection specifies the services configuration.
* docker: This subsection specifically refers to the Docker service configuration.
* memory: 3072: This line sets the memory limit for the Docker service to 3072 (presumably in megabytes or a similar unit).

By setting the memory limit for the Docker service, it restricts the amount of memory that the Docker service can utilize within the deployment environment. This can be useful for resource allocation and ensuring that the Docker service does not consume excessive memory, potentially impacting other processes or services running on the same machine or container orchestrator.
Please note that this snippet is likely part of a larger configuration file or infrastructure-as-code definition. The purpose of setting the memory limit for the Docker service may vary depending on the context and the specific deployment or orchestration system being used.

---

caches->sonar steps->Snyk_Check

                                  caches:
                                      sonar: ~/.sonar/cache
                                  steps:
                                      - step: &Snyk_Check 
                              

To define a cache configuration and a list of steps within a larger configuration file, possibly for a CI/CD pipeline.
* `caches`: This section defines caching configurations for the pipeline.
* `sonar: ~/.sonar/cache`: This line specifies a cache named "sonar" and sets the cache directory to ~/.sonar/cache. Caching is a technique used to store and reuse data between pipeline runs, potentially improving performance by avoiding redundant computations or downloads. In this case, the cache appears to be related to the SonarQube static code analysis tool, and it utilizes the ~/.sonar/cache directory as the cache location.

* `steps`: This section defines a list of steps for the pipeline.
* `- step: &Snyk_Check`: This line begins the definition of a pipeline step named "Snyk_Check" using the &Snyk_Check YAML anchor. The &Snyk_Check anchor can be referenced elsewhere in the YAML file to reuse this step configuration. The specific details of the step, such as its commands or actions, are likely provided in subsequent lines of the YAML file but are not shown in the provided snippet.

Overall, this snippet indicates the configuration of a cache for SonarQube and the definition of a step named "Snyk_Check" within a pipeline. The exact usage and details of the cache and step would depend on the larger context of the pipeline configuration.

---

pipelines->branches->branch names

                                pipelines:
                    
                                    branches:
                                        '**':
                                            - parallel:
                                                - step: *Sonar_Quality_Check
                                                - step: *Git_Secrets_Scan
                                                - step: *Snyk_Check
                    
                                        master:
                                            - parallel:
                                                - step: *Git_Secrets_Scan
                                                - step: *Snyk_Check
                                            - step: *Build_Push
                                            - step: *Prod_Deploy 
                              

The YAML snippet provided defines a pipeline configuration for different branches in a CI/CD setup using Bitbucket Pipelines.

• `pipelines`: This section defines the pipeline configuration.
• `branches`: This subsection specifies the branch-specific configurations.
• `**`: This is a glob pattern that matches any branch name.
• `- parallel:`: This line starts a parallel execution block, indicating that the listed steps within it will run concurrently.
• `step: *Sonar_Quality_Check`:This line refers to a step with the name "Sonar_Quality_Check" defined elsewhere in the YAML file. The *Sonar_Quality_Check anchor is used to reference the step configuration.
• `step: *Git_Secrets_Scan`: This line refers to a step with the name "Git_Secrets_Scan" defined elsewhere in the YAML file.
• `step: *Snyk_Check`: This line refers to a step with the name "Snyk_Check" defined elsewhere in the YAML file.
• `master`: This is the branch name for the "master" branch.
• `step: *Build_Push`: This line refers to a step with the name "Build_Push" defined elsewhere in the YAML file.
• `step: *Prod_Deploy`: This line refers to a step with the name "Prod_Deploy" defined elsewhere in the YAML file.

Pipelines Steps

Step 3: Let's define the steps used in bitbucket-pipelines.yml file

Snyk_Check

The added step for Snyk vulnerability scanning. Snyk is a developer security platform that enables application and cloud developers to secure their whole application — finding and fixing vulnerabilities from their first lines of code to their running cloud.

                            - step: &Snyk_Check
                                name: 'Snyk'
                                script:
                                    - aws configure --profile mfa set aws_access_key_id $AWS_ACCESS_KEY_ID_IDK
                                    - aws configure --profile mfa set aws_secret_access_key $AWS_SECRET_ACCESS_KEY_IDK
                                    - aws configure --profile mfa set default.region $AWS_DEFAULT_REGION
                                    - npm install
                                    - pipe: snyk/snyk-scan:0.5.2
                                    variables:
                                        SNYK_TOKEN: ${SNYK_TOKEN_FOR_APP}
                                        LANGUAGE: "npm"
                                        DONT_BREAK_BUILD: "true"
                            

Lets understand, what happening in the above script:

* (A). Configures the AWS CLI with the provided access key ID and other values for the profile named "mfa". The aws_access_key_id and others values are fetched from the BitBucket repository variable.
* (B). npm install: Executes the npm install command to install the project dependencies.
* (C). pipe: snyk/snyk-scan:0.5.2: Uses the Snyk vulnerability scanning pipe with the specified version 0.5.2. Pipes are pre-configured Docker containers that can execute specific tasks within the pipeline.
* (D). variables:: Starts the section for defining variables specific to the Snyk pipe.
* (E). LANGUAGE: "npm": Specifies the programming language used in the project, which is set to "npm" in this case.
* (F). DONT_BREAK_BUILD: "true": Sets the DONT_BREAK_BUILD variable to "true", indicating that the build should not fail even if vulnerabilities are found during the Snyk scan.

This code block configures the BitBucket pipeline to execute the Snyk vulnerability scanning pipe, leveraging the AWS CLI to set up the necessary AWS credentials and region for the Snyk scan. The script also includes the installation of project dependencies using npm.

Sonar_Quality_Check

                            - step: &Sonar_Quality_Check
                                name: 'Sonar Quality Check and Gate'
                                caches:
                                  - sonar
                                  - node
                                script:
                                  - export SONAR_TOKEN=$SONAR_TOKEN
                                  - export SONAR_URL=https://sonarcloud.io/
                                  - export SONAR_ORG=idkblogs-solutions-co
                                  - export SONAR_PROJECT_KEY=idkblogs-sonar-key
                                  - export NODE_ENV=uat
                                  - pipe: sonarsource/sonarcloud-scan:1.4.0
                                    variables:
                                      SONAR_TOKEN: ${SONAR_TOKEN}
                                      EXTRA_ARGS: '-Dsonar.projectKey=$SONAR_PROJECT_KEY -Dsonar.organization=$SONAR_ORG -Dsonar.projectName=$SONAR_PROJECT_KEY -Dsonar.projectVersion=$BITBUCKET_COMMIT -Dsonar.host.url=$SONAR_URL -Dsonar.sources=src -Dsonar.tests=src -Dsonar.test.inclusions="**/testing/**,**/*.spec.ts" -Dsonar.typescript.lcov.reportPaths=code-coverage/lcov.info'
                                  - pipe: sonarsource/sonarcloud-quality-gate:0.1.6
                                    variables:
                                      SONAR_TOKEN: ${SONAR_TOKEN}
                                      SONAR_QUALITY_GATE_TIMEOUT: "180"
                            

Lets understand, what happening in the above script:
The code snippet above is an additional step in the BitBucket pipeline configuration for performing Sonar Quality Check.

• The caches section specifies the caches that will be used in this step. In this case, the sonar and node caches are defined, which helps to speed up subsequent pipeline runs by caching dependencies.
• The export statements set environment variables required for SonarCloud analysis, such as SONAR_TOKEN, SONAR_URL, SONAR_ORG, SONAR_PROJECT_KEY, and NODE_ENV.
• The pipe command is used to run a Docker container provided by SonarSource for SonarCloud analysis. The sonarsource/sonarcloud-scan:1.4.0 container is used, and the variables section defines environment variables for the container, including SONAR_TOKEN and EXTRA_ARGS. The EXTRA_ARGS variable provides additional configuration options for the SonarCloud analysis, such as project key, organization, project name, version, source directories, test directories, and code coverage report paths.
• After the SonarCloud analysis, the pipeline uses another SonarSource provided Docker container, sonarsource/sonarcloud-quality-gate:0.1.6, to check the quality gate status. The variables section sets the SONAR_TOKEN and SONAR_QUALITY_GATE_TIMEOUT environment variables. The SONAR_QUALITY_GATE_TIMEOUT specifies the maximum time to wait for the quality gate to complete.

This step ensures that the code quality is analyzed and a quality gate is applied to enforce specific quality criteria before proceeding with the deployment.

Git_Secrets_Scan

                            - step: &Git_Secrets_Scan
                                name: 'Git Secrets Scan'
                                script:
                                  - pipe: atlassian/git-secrets-scan:0.6.0
                            

Lets understand, what happening in the above script:
Here is an explanation of the additional step in the BitBucket pipeline configuration for Git Secrets Scan.

• The pipe command is used to run a Docker container provided by Atlassian for Git Secrets scanning. The atlassian/git-secrets-scan:0.6.0 container is used to perform the scan for potential secrets in the repository.
• This step helps identify any potential secrets, such as API keys or sensitive information, that may have been accidentally committed to the repository.

It is crucial to scan for and remove any sensitive information from the source code to ensure the security and integrity of your application. The Git Secrets Scan step helps to automate this process by running the scan within the pipeline, alerting you of any potential issues that need to be addressed.

Test_case

                            - step: &Test_case
                                name: "Test case check"
                                caches:
                                - node
                                script:
                                - export SONAR_PROJECT_KEY=idkblogs-sonar-key
                                - npm install
                                - npm run test
                                artifacts:
                                - code-coverage/lcov.info
                                - test-report.xml
                            

Lets understand, what happening in the above script:
Here is an explanation of the additional step in the BitBucket pipeline configuration for running test cases:

• The caches section specifies the cache to be used in this step, which is the node cache. This cache helps to speed up subsequent pipeline runs by caching Node.js dependencies.
• The export statement sets the SONAR_PROJECT_KEY environment variable, which might be required for further analysis or reporting.
• The npm install command is used to install the Node.js dependencies required for running the tests.
• The npm run test command executes the test suite for the Node.js application.
• The artifacts section specifies the files that should be saved as artifacts after the step completes. In this case, the code-coverage/lcov.info file, which contains the code coverage information, and the test-report.xml file, which contains the test results, will be saved as artifacts.

This step ensures that the test cases for the Node.js application are executed, providing valuable information about the code coverage and test results. The artifacts generated in this step can be used for further analysis or reporting purposes.

Build_Push

                            - step: &Build_Push
                                name: 'Build and Push'
                                size: 2x
                                services:
                                    - docker
                                caches:
                                    - sonar
                                script:
                                    - docker version
                                    - aws configure set default.region $AWS_DEFAULT_REGION
                                    - aws configure set aws_access_key_id $AWS_ACCESS_KEY_ID_IDK_EKS
                                    - aws configure set aws_secret_access_key $AWS_SECRET_ACCESS_KEY_IDK_EKS
                                    - export APP_NAME=idkblogs
                                    - export AWS_ECR_REPOSITORY=123456789012.dkr.ecr.ap-south-2.amazonaws.com/$APP_NAME
                                    - export IMAGE_NAME_COMMIT=$AWS_ECR_REPOSITORY:$BITBUCKET_BRANCH-$BITBUCKET_COMMIT
                                    - echo "export TAG=$BITBUCKET_BRANCH-$BITBUCKET_COMMIT" > TAG.txt
                                    - node -v
                                    - export NODE_ENV=production
                                    - aws configure --profile mfa set aws_access_key_id $AWS_ACCESS_KEY_ID_IDK
                                    - aws configure --profile mfa set aws_secret_access_key $AWS_SECRET_ACCESS_KEY_IDK
                                    - aws configure --profile mfa set default.region $AWS_DEFAULT_REGION
                                    - npm install
                                    - npm install -g @nestjs/cli
                                    - npm prune
                                    - curl -sf https://gobinaries.com/tj/node-prune | sh
                                    - npm run build
                                    - node-prune
                                    - echo "$(ls -la dist/)"
                                    - aws ecr get-login-password --region ap-south-2 | docker login --username AWS --password-stdin 123456789012.dkr.ecr.ap-south-2.amazonaws.com
                                    - docker build -t $IMAGE_NAME_COMMIT .
                                    - docker push $IMAGE_NAME_COMMIT
                                    - echo "export BITBUCKET_BUILD_NUMBER=$IMAGE_NAME_COMMIT" > set_env.sh
                                    - cat set_env.sh
                                artifacts:
                                    - node_modules/
                                    - dist/
                                    - .scannerwork/report-task.txt
                                    - TAG.txt
                                    - set_env.sh
                            

Lets understand, what happening in the above script:
Here is an explanation of the additional step in the BitBucket pipeline configuration for building and pushing the Docker image:

Explanation:

This step builds the Docker image, pushes it to the ECR registry, and saves relevant artifacts for further reference or deployment.

Example image of docker image uploaded on AWS ECR

Prod_Deploy

                                
                            - step: &Prod_Deploy
                                name: 'prod-deploy'
                                image: atlassian/pipelines-awscli
                                oidc: true
                                script:
                                    - apk add curl
                                    - curl -o kubectl https://s3.us-west-2.amazonaws.com/amazon-eks/1.18.9/2020-11-02/bin/linux/amd64/kubectl
                                    - mkdir ~/.kube
                                    - cp .kube/config ~/.kube/config
                                    - chmod +x ./kubectl
                                    - mkdir -p $HOME/bin && cp ./kubectl $HOME/bin/kubectl && export PATH=$PATH:$HOME/bin
                                    - export AWS_REGION=ap-south-2
                                    - export AWS_ROLE_ARN=$AWS_IDK_BITBUCKET_OIDC_ROLE
                                    - export IMGTAG=$BITBUCKET_BRANCH-$BITBUCKET_COMMIT
                                    - export TAG=$BITBUCKET_BRANCH-$BITBUCKET_COMMIT
                                    - export AWS_WEB_IDENTITY_TOKEN_FILE=$(pwd)/web-idk-identity-token
                                    - echo $BITBUCKET_STEP_OIDC_TOKEN > $(pwd)/web-idk-identity-token
                                    - sed -i 's/\$IMGTAG'"/$TAG/g" .kube/kube-prod-eks-deployment.yml
                                    - ./kubectl config get-contexts
                                    - kubectl config use-context arn:aws:eks:ap-south-2:123456654321:cluster/AWS-MUM-DEV-IDK-BE
                                    - kubectl apply -f .kube/kube-prod-eks-deployment.yml # Create the objects defined in kube-prod-eks-deployment.yml file in a directory:
                                services:
                                    - docker
                            

Lets understand, what happening in the above script:

Step 4: Enable pipeline and Configure BitBucket Repository Variables

in this step, we need to enable the bitbucket pipeline from bitbucket.

Example image to enable the bitbucket pipelines for CI/CD

Configure BitBucket Repository Variables whatevery required in your bitbucket-pipelines.yml file.

(A). In your BitBucket repository, navigate to the "Settings" tab.

(B). Select "Repository settings" and click on "Repository variables."

(C). Add the following environment variables:

For eaxample

Example image to add the environment variable for CI/CD

                                AWS_ACCESS_KEY_ID: [Your AWS Access Key ID]
                                AWS_SECRET_ACCESS_KEY: [Your AWS Secret Access Key]
                                AWS_DEFAULT_REGION: [Your AWS region, e.g., us-west-2]
                                AWS_ACCOUNT_ID: [Your AWS Account ID]
                            

Step 5: Let's have a quick look on .kube directory

.kube/config

                                apiVersion: v1
                                clusters:
                                - cluster:
                                    certificate-authority-data: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tL...0FURS0tLS0tCg==
                                    server: https://80ABCDEFGHIJKLMNOPQRSTUVWXYZ.gr7.ap-south-2.eks.amazonaws.com
                                name: arn:aws:eks:ap-south-2:12345678:cluster/AWS-MUM-DEV-IDK-BE
                                contexts:
                                - context:
                                    cluster: arn:aws:eks:ap-south-2:12345678:cluster/AWS-MUM-DEV-IDK-BE
                                    user: arn:aws:eks:ap-south-2:12345678:cluster/AWS-MUM-DEV-IDK-BE
                                name: arn:aws:eks:ap-south-2:12345678:cluster/AWS-MUM-DEV-IDK-BE
                                current-context: arn:aws:eks:ap-south-2:12345678:cluster/AWS-MUM-DEV-IDK-BE
                                kind: Config
                                preferences: {}
                                users:
                                - name: arn:aws:eks:ap-south-2:12345678:cluster/AWS-MUM-DEV-IDK-BE
                                user:
                                    exec:
                                    apiVersion: client.authentication.k8s.io/V1TEST1.1
                                    args:
                                    - --region
                                    - ap-south-2
                                    - eks
                                    - get-token
                                    - --cluster-name
                                    - AWS-MUM-DEV-IDK-BE
                                    command: aws
                            

Example image of config file in .kube directory

Let's understand the above configuration file.

And here is the sample file kube-prod-eks-deployment.yml file to create objects, and services in the Kubernetes dashboard.

.kube/kube-prod-eks-deployment.yml

                                ---
                                apiVersion: $APIVERSION
                                kind: Deployment
                                metadata:
                                labels:
                                    app: test-app-dev
                                name: test-app-dev
                                namespace: idk-myapps-dev
                                spec:
                                replicas: 1
                                selector:
                                    matchLabels:
                                    app: test-app-dev
                                strategy:
                                    rollingUpdate:
                                    maxSurge: 100%
                                    maxUnavailable: 0
                                    type: RollingUpdate
                                template:
                                    metadata:
                                    labels:
                                        app: test-app-dev
                                    spec:
                                    serviceAccountName: kafka-myuat-idk-myapps
                                    containers:
                                        - env:
                                            - name: NODE_ENV
                                            value: dev
                                            - name: PORT
                                            value: '3000'
                                            - name: APP_NAME
                                            value: test-app-dev
                                            - name: BASE_PATH
                                            value: dev/idk-blogs
                                            - name: DD_AGENT_HOST
                                            valueFrom:
                                                fieldRef:
                                                apiVersion: v1
                                                fieldPath: status.hostIP 
                                            - name: SOME_VALUE_FROM_AWS_SECRETS
                                            valueFrom:
                                                secretKeyRef:
                                                key: BLOGS_DB_URL_RW
                                                name: idk-blogs-secret-dev
                                        image: 123456789012.dkr.ecr.ap-south-2.amazonaws.com/idk-blogs:$IMGTAG
                                        livenessProbe:
                                            failureThreshold: 3
                                            httpGet:
                                            path: /dev/idk-blogs/health/live
                                            port: 3000
                                            scheme: HTTP
                                            initialDelaySeconds: 60
                                            periodSeconds: 30
                                            successThreshold: 1
                                            timeoutSeconds: 1
                                        readinessProbe:
                                            failureThreshold: 5
                                            httpGet:
                                            path: /dev/idk-blogs/health/ready
                                            port: 3000
                                            scheme: HTTP
                                            initialDelaySeconds: 60
                                            periodSeconds: 30
                                            successThreshold: 1
                                            timeoutSeconds: 1
                                        startupProbe:
                                            httpGet:
                                            path: /dev/idk-blogs/health/startup
                                            port: 3000
                                            scheme: HTTP
                                            failureThreshold: 30
                                            periodSeconds: 30
                                        lifecycle:
                                            preStop:
                                            exec:
                                                command:
                                                - /bin/sh
                                                - '-c'
                                                - "kill $(ps -e | grep node | awk '{print $1}')"
                                        imagePullPolicy: Always
                                        name: idk-blogs
                                        ports:
                                            - containerPort: 3000
                                            protocol: TCP
                                        resources:
                                            limits:
                                            cpu: 500m
                                            memory: 1800Mi
                                            requests:
                                            cpu: 100m
                                            memory: 1000Mi
                                    dnsConfig:
                                        options:
                                        - name: ndots
                                            value: '1'
                                    restartPolicy: Always
                    
                                #idk-blogs  Service
                                ---
                                apiVersion: v1
                                kind: Service
                                metadata:
                                name: test-app-dev
                                namespace: idk-myapps-dev
                                spec:
                                type: ClusterIP
                                ports:
                                    - name: test-app-dev
                                    port: 3000
                                    targetPort: 3000
                                    protocol: TCP
                                selector:
                                    app: test-app-dev
                    
                            

Step 6: Triggering the CI/CD Pipeline

Commit and push your code changes to the BitBucket repository.

The BitBucket pipeline will automatically start running.

The pipeline will build your Node.js application, create a Docker image, and push it to the AWS ECR repository, create your project in configured Kubernetes.

Let's understand some of the commands used in this CI/CD:

---

aws configure --profile mfa set aws_access_key_id $AWS_ACCESS_KEY_ID

The script line "aws configure --profile mfa set aws_access_key_id $AWS_ACCESS_KEY_ID" in a Bitbucket Pipeline step is configuring the AWS CLI with the provided AWS access key ID.

Let's break down the command:

* aws configure: This is the AWS CLI command used to configure the AWS CLI settings.
* -profile mfa: This specifies the name of the AWS CLI profile to be configured. In this case, the profile name is "mfa".
* set: This is a subcommand of aws configure that sets the configuration values for the specified profile.
* aws_access_key_id $AWS_ACCESS_KEY_ID: This sets the value of the AWS access key ID for the specified profile. The value is being passed from an environment variable called $AWS_ACCESS_KEY_ID.
In Bitbucket Pipelines, environment variables can be set at the pipeline level or within individual steps. In this case, the AWS access key ID is expected to be provided as an environment variable $AWS_ACCESS_KEY_ID, which will be passed to the aws configure command to set the access key ID for the "mfa" profile.
This configuration is typically required if you want to use AWS CLI commands within your Bitbucket Pipeline, such as deploying to an AWS service or interacting with AWS resources. The access key ID is used to authenticate and authorize access to your AWS account and resources.

---

aws configure set default.region $AWS_DEFAULT_REGION

The script line "aws configure set default.region $AWS_DEFAULT_REGION" in a Bitbucket Pipeline step is configuring the default AWS region for the AWS CLI.

---

echo "export TAG=$BITBUCKET_BRANCH-$BITBUCKET_COMMIT" > TAG.txt"

The script line "echo "export TAG=$BITBUCKET_BRANCH-$BITBUCKET_COMMIT" > TAG.txt" in a Bitbucket Pipeline step is creating a file called "TAG.txt" and storing an environment variable value in it.

---

curl -sf https://gobinaries.com/tj/node-prune | sh

The script line "curl -sf https://gobinaries.com/tj/node-prune | sh" in a Bitbucket Pipeline step is downloading and executing a script called "node-prune" using the curl and sh commands.
In summary, this script line uses curl to download the script "node-prune" from the specified URL, and then pipes the downloaded script to the sh command, which executes it.
The purpose of this script could vary depending on the specific pipeline and project requirements. Generally, it suggests that "node-prune" is being used as part of the pipeline to perform some actions related to Node.js dependencies or project cleanup. It could be used to remove unnecessary or unused dependencies from a Node.js project or perform other related tasks.

---

"aws ecr get-login-password --region ap-south-2 | docker login --username AWS --password-stdin 123456789012.dkr.ecr.ap-south-2.amazonaws.com"

The script line "aws ecr get-login-password --region ap-south-2 | docker login --username AWS --password-stdin 123456789012.dkr.ecr.ap-south-2.amazonaws.com" in a Bitbucket Pipeline step is performing authentication and logging in to an Amazon Elastic Container Registry (ECR) using the AWS CLI and Docker commands.
In summary, this script line retrieves the authentication token (password) for an AWS ECR registry in the "ap-south-2" region using the AWS CLI command aws ecr get-login-password, and then uses that token to perform a Docker login to the ECR registry using the docker login command.
This authentication and login step is necessary to access and interact with the ECR registry. It ensures that the Docker client is authenticated and authorized to push or pull container images from the specified ECR repository.

---

"curl -o kubectl https://s3.us-west-2.amazonaws.com/amazon-eks/1.18.9/2020-11-02/bin/linux/amd64/kubectl"

The script line "curl -o kubectl https://s3.us-west-2.amazonaws.com/amazon-eks/1.18.9/2020-11-02/bin/linux/amd64/kubectl" in a Bitbucket Pipeline step is downloading the kubectl binary from the specified URL using the curl command.
In summary, this script line uses curl to download the kubectl binary from the specified URL and saves it as a file named "kubectl". The kubectl binary is a command-line tool used to interact with Kubernetes clusters.
This line is typically used in a Bitbucket Pipeline step to ensure that the kubectl binary is available for subsequent Kubernetes-related operations. By downloading the kubectl binary, the pipeline can execute commands against a Kubernetes cluster, such as deploying applications, managing resources, or retrieving cluster information.

---

"chmod +x ./kubectl"

The script line "chmod +x ./kubectl" in a Bitbucket Pipeline step is granting executable permissions to the kubectl binary file located in the current directory.
`+x`: This is an argument provided to the chmod command, where`+x` specifies adding executable permissions.
In summary, this script line sets the executable permissions for the kubectl binary file, allowing it to be executed as a command. The +x argument adds the executable permission for the file, enabling it to be run by the user.
Setting executable permissions with chmod +x is necessary to execute the kubectl binary file as a command-line tool in subsequent steps of the pipeline. Once the permissions are granted, you can use the kubectl command to interact with Kubernetes clusters and perform various operations, such as managing resources, deploying applications, or retrieving cluster information.

---

"sed -i 's/\$IMGTAG'"/$TAG/g" .kube/kube-prod-eks-deployment.yml"

The script line "sed -i 's/$IMGTAG'"/$TAG/g" .kube/kube-prod-eks-deployment.yml" in a Bitbucket Pipeline step is using the sed command to replace occurrences of the $IMGTAG placeholder with the value of the $TAG variable in the specified YAML file.
In summary, this script line uses sed to modify the specified YAML file (kube-prod-eks-deployment.yml). It searches for the exact string $IMGTAG and replaces it with the value of the $TAG variable. The modification is done directly in the file due to the -i option.
This substitution operation is commonly used to dynamically update values in configuration files or templates during the deployment process. In this case, it allows you to replace the $IMGTAG placeholder in the YAML file with the value of the $TAG variable, which can be set dynamically in the Bitbucket Pipeline based on the requirements of the deployment.

---

"./kubectl config get-contexts"

The script line "./kubectl config get-contexts" in a Bitbucket Pipeline step is executing the kubectl command to retrieve the available Kubernetes contexts configured on the system.
In Kubernetes, a context is a set of access parameters that determine the cluster, user, and namespace that kubectl will interact with. It allows you to switch between different clusters or environments easily.
By running the kubectl config get-contexts command, the pipeline is retrieving the list of available contexts configured on the system. This information includes the name of each context, the associated cluster, the user, and the namespace. It provides visibility into the different Kubernetes environments or clusters that can be targeted for deployments or other operations.
This command can be useful for debugging or verifying the correct configuration of kubectl and the available contexts in your Bitbucket Pipeline setup.

---

"kubectl config use-context arn:aws:eks:ap-south-2:123456654321:cluster/AWS-MUM-DEV-IDK-BE"

The script line "kubectl config use-context arn:aws:eks:ap-south-2:123456654321:cluster/AWS-MUM-DEV-IDK-BE" in a Bitbucket Pipeline step is using the kubectl command to set the current Kubernetes context to the specified context name.
Let's break down the command:
`kubectl`: This is the command-line tool used to interact with Kubernetes clusters.
`config use-context`: This is a kubectl command that sets the current context to the specified context name.
"arn:aws:eks:ap-south-2:123456654321:cluster/AWS-MUM-DEV-IDK-BE": This is the name of the context to be set. In this case, it appears to be an Amazon EKS (Elastic Kubernetes Service) context, identified by an ARN (Amazon Resource Name). The context name includes the AWS region (ap-south-2) and the specific EKS cluster identifier (AWS-MUM-DEV-IDK-BE).

Setting the Kubernetes context allows kubectl to determine the target cluster, user, and namespace for subsequent operations. By using the kubectl config use-context command, the pipeline is instructing kubectl to switch to the specified EKS context, enabling subsequent kubectl commands to interact with the designated EKS cluster.
This command is typically used when working with multiple Kubernetes clusters or environments, allowing the pipeline to target a specific cluster for deployment, management, or other operations.

---

"kubectl apply -f .kube/kube-prod-eks-deployment.yml"

The script line "kubectl apply -f .kube/kube-prod-eks-deployment.yml" in a Bitbucket Pipeline step is using the kubectl command to apply the configuration defined in the "kube-prod-eks-deployment.yml" YAML file to the Kubernetes cluster.
When running the kubectl apply command, it reads the YAML file specified with the -f flag and applies the resource definitions within it to the Kubernetes cluster. The resources defined in the YAML file could include deployments, services, pods, or any other Kubernetes objects.
By executing this command in the Bitbucket Pipeline, the pipeline is deploying or updating the resources defined in the "kube-prod-eks-deployment.yml" file to the designated Kubernetes cluster. This allows for automated deployments or updates of Kubernetes applications as part of the pipeline process.

Conclusion:

Integrating BitBucket CI/CD with AWS ECR offers a powerful solution for automating your Node.js application deployment process. By following the steps outlined in this article, you can set up a robust CI/CD pipeline that streamlines your development workflow. BitBucket's easy configuration and AWS ECR's scalability and reliability make them a perfect combination for managing and deploying your containerized Node.js applications.

With BitBucket's version control capabilities and AWS ECR's secure and scalable container registry, you can ensure that your application's code is properly versioned, tested, and deployed in a consistent and efficient manner. The integration allows you to automate the building and pushing of Docker images, making it easier to manage your application's lifecycle from development to production.

By leveraging BitBucket's pipelines and AWS ECR's container management features, you can significantly reduce the time and effort required for manual deployment processes. This automation not only improves efficiency but also reduces the risk of human error and ensures consistent deployments across different environments.

Furthermore, the integration of BitBucket CI/CD with AWS ECR enables seamless collaboration among team members. Developers can work concurrently on different branches, and the CI/CD pipeline ensures that changes are tested and deployed automatically, promoting a continuous integration and deployment culture within your development team.

In conclusion, by harnessing the power of BitBucket CI/CD and AWS ECR, you can achieve efficient, reliable, and scalable deployment workflows for your Node.js applications. Embracing these tools empowers you to focus more on developing quality code and delivering value to your users while leaving the repetitive and error-prone tasks of building, testing, and deploying to the automated pipeline.

Related Keywords:

BitBucket CI/CD with AWS ECR and Kubernetes

Container Image Management

AWS Elastic Kubernetes Service (EKS)

Bitbucket CI/CD with AWS ECR and kubernetes

Bitbucket EKS deployment

Bitbucket CI CD with AWS ECR and kubernetes example

Bitbucket ECS Deploy

Bitbucket Kubernetes

Bitbucket pipeline push to ERC