DEV Community: marocz

Automating EKS Deployment and NGINX Setup Using Helm with AWS CDK in Python

marocz — Thu, 25 Apr 2024 23:00:00 +0000

Introduction

Amazon Elastic Kubernetes Service (EKS) simplifies the process of running Kubernetes on AWS. When combined with the power of Helm and the AWS Cloud Development Kit (CDK), you can automate the deployment of Kubernetes resources and applications efficiently. This guide will walk you through deploying an EKS cluster and setting up NGINX using Helm, all automated with AWS CDK in Python.

Prerequisites

AWS CLI configured with administrator access.
AWS CDK installed (npm install -g aws-cdk).
Python 3.x installed.
Docker installed (for building the CDK app).

Step 1: Bootstrap Your CDK Project

First, create a new directory for your CDK project and initialize a new CDK app:

mkdir eks-cdk-nginx
cd eks-cdk-nginx
cdk init app --language python

Step 2:

Ensure you have all the required dependencies on the requirement.txt file


aws-cdk-lib==2.133.0
constructs>=10.0.0,<11.0.0
python-dotenv==1.0.1
boto3==1.34.71
pytest==6.2.5
moto==5.0.4

Install the necessary CDK libraries for EKS:

pip install -r requirement.txt

Understanding the AWS CDK Initialization Process

When you initialize a new AWS Cloud Development Kit (CDK) project with cdk init app --language python, several things happen:

Project Structure Creation: CDK creates a new directory with the name of your project and establishes a standard project structure within it.
Initialization of CDK App: A CDK application is initialized within this directory. This app will serve as the container for your CDK stacks and constructs.
Generation of Configuration Files and Directories: The command generates several configuration files and directories essential for your project, including:

- `app.py`: The entry point for your CDK application.
- `cdk.json`: Contains configuration for the CDK app, like which command to use for synthesizing CloudFormation templates.
- `requirements.txt`: Lists the Python packages required by your CDK app.
- `setup.py`: A setup script for installing the module (app) and its dependencies.
- A `.env` directory for your virtual environment and a `source.bat` or `source.sh` script (depending on your OS) to activate it.

Virtual Environment Setup: It suggests commands to set up a virtual environment for Python and to install the dependencies listed in requirements.txt.

How to Structure Your CDK Project

Your AWS CDK project should be structured in a way that supports scalability and maintainability:

App and Stack Files: The app.py file is where you instantiate your app and stacks. Each stack should be defined in its separate Python file for clarity, e.g., my_stack.py.
Resource Constructs: Individual constructs, representing AWS resources, should be defined within stack files or in separate files if they are custom constructs or if you plan to reuse them across different stacks.
Lib Directory: For larger projects, you might want to organize your constructs and stacks in a lib/ directory. Each stack can have its own file within this directory.
Test Directory: Tests for your CDK constructs and stacks should be placed in a test/ directory.
Assets: Store any assets (like Lambda code or Dockerfiles) in an assets/ or resources/ directory.

Creating a Construct

A construct in CDK is a building block of your AWS infrastructure, representing an AWS resource or a group of related resources. Here’s how to create a simple S3 bucket construct within a stack:

Define Your Construct: In your stack file (my_stack.py), import the necessary AWS modules and define your construct:

from aws_cdk import aws_s3 as s3
from aws_cdk import core

class MyStack(core.Stack):
    def __init__(self, scope: core.Construct, id: str, **kwargs):
        super().__init__(scope, id, **kwargs)

        s3.Bucket(self, "MyFirstBucket",
            versioned=True,
            removal_policy=core.RemovalPolicy.DESTROY)

Creating a Stack

A stack in CDK represents a collection of AWS resources that you deploy together. The MyStack class in the example above is already a stack. You instantiate this stack in your app.py:

from aws_cdk import core
from my_stack import MyStack

app = core.App()
MyStack(app, "MyStack")
app.synth()

Running `cdk synth` and What to Expect

The cdk synth command synthesizes your CDK code into an AWS CloudFormation template.

Command: Run cdk synth from the root directory of your CDK project.
Output: This command outputs a CloudFormation template in YAML format to your terminal. This template describes all the AWS resources you've defined in your CDK code.
CloudFormation Template: The template can be found in the cdk.out directory, named after your stack, e.g., MyStack.template.json.
What to Look For: Verify that the resources defined in your CDK stack, such as the S3 bucket in our example, are correctly represented in the CloudFormation template.

This synthesized template is what AWS CloudFormation uses to deploy and manage the defined cloud resources, making cdk synth an essential step in the development process to validate your infrastructure definitions before deployment.

Step 2: Define Your EKS Cluster in CDK

In the eks_cdk_nginx directory, modify the eks_cdk_nginx_stack.py file to define your EKS cluster. The following example creates an EKS cluster and an EC2 instance as the worker node:

from aws_cdk import core
from aws_cdk import aws_eks as eks
from aws_cdk import aws_ec2 as ec2

class EksCdkNginxStack(core.Stack):

    def __init__(self, scope: core.Construct, construct_id: str, **kwargs) -> None:
        super().__init__(scope, construct_id, **kwargs)

        # Define the VPC
        vpc_id="vpc-xxxxxxxx"
        vpc = ec2.Vpc.from_lookup(self, "vpc", vpc_id=vpc_id)
        print("This is the vpc ", vpc.vpc_id)
        vpc_subnets = [{'subnetType': ec2.SubnetType.PUBLIC}]
        #    vpc_subnets=vpc.select_subnets(subnet_type=ec2.SubnetType.PUBLIC).subnets

        # create eks admin role
        eks_master_role = iam.Role(self, 'EksMasterRole',
                                   role_name='EksAdminRole',
                                   assumed_by=iam.AccountRootPrincipal()
                                   )

        # Define the EKS cluster
       cluster = eks.Cluster(self, 'Cluster',
                              vpc=vpc,
                              version=eks.KubernetesVersion.V1_25,
                              masters_role=eks_master_role,
                              default_capacity=0,
                              vpc_subnets=vpc_subnets
                              )

Step 3: Add NGINX Ingress Using Helm

The AWS CDK’s EKS module allows you to define Helm charts as part of your infrastructure. Extend your stack to include the NGINX ingress controller from Helm:


        # Add NGINX ingress using Helm
        eks.HelmChart(
            self, "NginxIngress",
            cluster=cluster,
            chart="ingress-nginx",
            repository="https://kubernetes.github.io/ingress-nginx",
            namespace="ingress-nginx",
            values=helm_values
        )

Step 4: Deploy Your CDK Stack

Ensure you are in the root of your CDK project and run the following commands to deploy your EKS cluster along with NGINX:

cdk synth
cdk deploy

This process might take several minutes as it sets up the EKS cluster and deploys the NGINX ingress controller.

Step 5: Verify the NGINX Deployment

Once the deployment is complete, you can verify the NGINX ingress controller is running by fetching the Helm releases in your cluster:

Update your kubeconfig:

aws eks update-kubeconfig --name MyCluster

List Helm releases to see NGINX installed:

helm ls -n kube-system

Adding Unit Tests to Your AWS CDK Project

Unit testing is an essential part of the development process, ensuring that your infrastructure as code behaves as expected. AWS CDK projects, being code-based, allow for straightforward unit testing of your infrastructure definitions. This section will guide you through setting up and writing unit tests for your AWS CDK project using Python.

Setting Up Your Testing Environment

Install Testing Libraries: To write and run tests, you'll need to install some additional Python libraries. pytest is a popular testing framework, and aws-cdk.assertions provides utilities for asserting CDK-specific conditions. Add these to your requirements.txt:
```
pytest
aws-cdk.assertions
```
Then, install them using pip:
```
pip install -r requirements.txt
```
Organize Test Directory: Create a tests directory in your project root. This is where all your test files will reside. You might structure it further into unit and integration tests if needed.
```
mkdir tests
```

Writing Unit Tests

Create a Test File: Inside the tests directory, create a Python file for your tests, for example, test_my_stack.py.
Import Testing Modules: At the beginning of your test file, import the necessary modules, including the CDK constructs you wish to test, pytest, and any CDK assertions you need.
```
import pytest
from aws_cdk import core
from aws_cdk.assertions import Template
from my_cdk_app.my_stack import MyStack
```

Write Test Cases: Write functions to test various aspects of your stack. Use the Template.from_stack function to create a template object from your stack, which you can then assert against.

def test_s3_bucket_created():
    app = core.App()
    stack = MyStack(app, "MyStack")
    template = Template.from_stack(stack)

    template.has_resource_properties("AWS::S3::Bucket", {
        "VersioningConfiguration": {
            "Status": "Enabled"
        }
    })

This test checks that your stack creates an S3 bucket with versioning enabled.

Testing Custom Constructs: If you have custom constructs, you can test them in isolation by instantiating them within a test stack in your test case, then making assertions about their template representation.

Running Your Tests

Execute your tests by running pytest in your project's root directory. pytest will automatically discover and run all test files in the tests directory.
```
pytest
```
If your tests pass, pytest will indicate success. If not, it will provide detailed output about which tests failed and why.

Conclusion on Unit Testing

Unit testing your AWS CDK project is crucial for maintaining high-quality infrastructure code. By testing your stacks and constructs, you ensure that your cloud infrastructure behaves as expected, reducing the likelihood of deployment errors and potential runtime issues. Incorporating these tests into a CI/CD pipeline can further automate your testing and deployment process, leading to more reliable and efficient infrastructure management.

Conclusion

You've successfully automated the deployment of an Amazon EKS cluster and set up NGINX using Helm, all with the AWS Cloud Development Kit (CDK) in Python. This approach not only simplifies the process of deploying and managing Kubernetes resources on AWS but also leverages the power of infrastructure as code for repeatable and consistent deployments.

Embrace the flexibility and efficiency of automating your cloud infrastructure with CDK, and explore further integrations and optimizations for your Kubernetes deployments on AWS.

Building Container Images Securely on AWS EKS with Kaniko

marocz — Thu, 11 Apr 2024 23:00:00 +0000

Introduction

In the world of Kubernetes, building container images securely and efficiently is a common challenge. This is where Kaniko comes in. Kaniko is a tool to build container images from a Dockerfile, inside a container or Kubernetes cluster, without requiring root access. This post will delve into Kaniko's capabilities and provide a guide on setting it up within an AWS Elastic Kubernetes Service (EKS) cluster.

What is Kaniko?

Kaniko is an open-source tool developed by Google to build container images from a Dockerfile, securely in a Kubernetes cluster. Unlike traditional Docker builds that require privileged root access to perform tasks, Kaniko doesn't need Docker or privileged access, mitigating the security risks associated with container image builds.

Why Use Kaniko on AWS EKS?

Security: Builds container images without Docker daemon, reducing the attack surface.
Flexibility: Integrates seamlessly with various CI/CD tools and services.
Efficiency: Leverages Kubernetes cluster resources for image builds.

Setting Up Kaniko on AWS EKS

Let's walk through setting up Kaniko on an AWS EKS cluster to build and push a container image to Amazon Elastic Container Registry (ECR).

Prerequisites

An AWS account with access to EKS and ECR.
kubectl configured to interact with your EKS cluster.
AWS CLI configured on your machine.
Docker installed on your machine.
Credentials configured for Amazon ECR.

Step 1: Create an ECR Repository

First, create a repository in Amazon ECR where Kaniko will push the built images.



aws ecr create-repository --repository-name my-kaniko-example

Step 2: Configure IAM Permissions

Kaniko needs permissions to push images to ECR. Create an IAM policy that grants the required permissions and attach it to the role associated with your EKS nodes.

Create an IAM policy (kaniko-ecr-policy.json):



{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "ecr:GetAuthorizationToken",
                "ecr:BatchCheckLayerAvailability",
                "ecr:CompleteLayerUpload",
                "ecr:InitiateLayerUpload",
                "ecr:PutImage",
                "ecr:UploadLayerPart"
            ],
            "Resource": "*"
        }
    ]
}

Create the policy:



aws iam create-policy --policy-name KanikoECRPolicy --policy-document file://kaniko-ecr-policy.json

Attach the policy to your EKS node role.

After creating the IAM policy that grants Kaniko permissions to push images to Amazon ECR, you need to attach this policy to the IAM role associated with your EKS nodes. This step is essential to grant the Kaniko pod the required AWS permissions.

Find Your EKS Node IAM Role

First, identify the IAM role used by your EKS nodes. You can find this information in the Amazon EKS console or by describing your EKS node group via AWS CLI:



aws eks describe-nodegroup --cluster-name your-cluster-name --nodegroup-name your-nodegroup-name

Look for the nodeRole in the output, which will be the ARN of the IAM role.

Attach the IAM Policy to the EKS Node Role

Once you have your EKS node IAM role ARN, attach the KanikoECRPolicy to it. You can do this through the AWS Management Console or the AWS CLI.

Using the AWS CLI:



aws iam attach-role-policy --role-name YourEKSNodeRoleName --policy-arn arn:aws:iam::your-account-id:policy/KanikoECRPolicy

Replace YourEKSNodeRoleName with the name of your EKS node IAM role (not the ARN) and your-account-id with your AWS account ID.

Verifying the Policy Attachment

Ensure the policy was attached successfully by listing the policies attached to your EKS node role:



aws iam list-attached-role-policies --role-name YourEKSNodeRoleName

You should see KanikoECRPolicy in the list of attached policies.

Step 3: Prepare Your Kubernetes Cluster

Create a Kubernetes secret to store your ECR credentials, which Kaniko will use to authenticate.



kubectl create secret docker-registry regcred \
    --docker-server=<AWS_REGION>.amazonaws.com \
    --docker-username=AWS \
    --docker-password=$(aws ecr get-login-password) \
    --docker-email=<YOUR_EMAIL>

Step 4: Deploy Kaniko Pod

Deploy a pod that uses Kaniko to build and push an image to your ECR repository. Define your deployment in a YAML file (kaniko-pod.yaml):



apiVersion: v1
kind: Pod
metadata:
  name: kaniko
spec:
  containers:
  - name: kaniko
    image: gcr.io/kaniko-project/executor:latest
    args: ["--dockerfile=Dockerfile",
           "--context=git://github.com/<your-repo>.git#refs/heads/master",
           "--destination=<AWS_ACCOUNT_ID>.dkr.ecr.<AWS_REGION>.amazonaws.com/my-kaniko-example:latest"]
    volumeMounts:
      - name: kaniko-secret
        mountPath: /kaniko/.docker
  restartPolicy: Never
  volumes:
    - name: kaniko-secret
      secret:
        secretName: regcred

Replace placeholders with your specific details. Deploy the pod:



kubectl apply -f kaniko-pod.yaml

Step 5: Verify the Image Build and Push

Monitor the pod's logs to ensure the build and push process completes successfully:



kubectl logs kaniko

Additional Method: Running Kaniko Inside a Docker Container

For local development or in CI/CD pipelines where Kubernetes isn't available, you can use Docker to run Kaniko using the Executor image from GCR. This approach simulates the Kubernetes environment, allowing you to build and push container images to a registry like Amazon ECR without needing a full Kubernetes setup.

Step 1: Pull the Kaniko Executor Image

First, pull the Kaniko Executor image from Google Container Registry:



docker pull gcr.io/kaniko-project/executor:latest

Step 2: Prepare Your Build Context and Dockerfile

Ensure your Dockerfile and any necessary files for the build (the build context) are located in a specific directory. This directory will be mounted into the Docker container running Kaniko.

Step 3: Run Kaniko in Docker

To build and push an image using Kaniko inside a Docker container, use the following command, adjusting paths and variables for your environment:



docker run \
  -v /path/to/your/build/context:/workspace \
  -v /path/to/.docker:/kaniko/.docker \
  gcr.io/kaniko-project/executor:latest \
  --dockerfile /workspace/Dockerfile \
  --context dir:///workspace/ \
  --destination=<AWS_ACCOUNT_ID>.dkr.ecr.<AWS_REGION>.amazonaws.com/my-kaniko-example:latest

/path/to/your/build/context is the local path to your Dockerfile and any files it needs.
/path/to/.docker should contain your config.json with the ECR credentials.
Adjust the --destination flag to point to your target ECR repository.

Step 4: Authenticate Docker with ECR

Ensure Docker is authenticated with Amazon ECR to allow pushing the built image. You can authenticate Docker using the AWS CLI:



aws ecr get-login-password --region <AWS_REGION> | docker login --username AWS --password-stdin <AWS_ACCOUNT_ID>.dkr.ecr.<AWS_REGION>.amazonaws.com

Step 5: Verify the Image in ECR

After the build completes, check your Amazon ECR repository to verify that the image has been pushed successfully.

Combining the Best of Both Worlds

Running Kaniko within a Docker container offers a versatile solution for building container images, especially when Kubernetes isn't part of your immediate toolchain. This method provides a bridge between local development environments and cloud-native technologies, allowing for a seamless transition to Kubernetes when ready.

Conclusion

Kaniko emerges as a robust tool for building container images securely, whether in a Kubernetes cluster with AWS EKS or locally using Docker. Its ability to run without Docker Daemon makes it a safer and more compliant choice for CI/CD pipelines, fitting well into various development and deployment workflows.

Mastering Kubernetes Admission Controllers: Setup and Use Cases

marocz — Sun, 07 Apr 2024 13:20:15 +0000

Introduction

Kubernetes Admission Controllers are pivotal in the Kubernetes API server pipeline, playing a crucial role in governing and regulating the objects being created, modified, or deleted. These controllers act as gatekeepers, enforcing policies and ensuring that the cluster's state is consistent and secure. This guide explores the functionality of Admission Controllers, their importance, and how you can set up a basic one for your cluster.

What are Kubernetes Admission Controllers?

Admission Controllers are plugins that intercept requests to the Kubernetes API server before the persistence of the object but after the request is authenticated and authorized. They can mutate (modify) or validate requests, offering a powerful mechanism to introduce custom logic and enforce policies across all Kubernetes resources.

Types of Admission Controllers

Validating Admission Webhooks: These inspect the requests and determine whether they should be allowed based on specific criteria.
Mutating Admission Webhooks: They can modify requests (e.g., adding labels or annotations) before they are processed by the validating webhooks.

Why Use Admission Controllers?

Admission Controllers enable:

Security Enhancements: Enforcing best practices and security policies, like preventing privileged containers.
Resource Management: Ensuring that resources request limits or namespaces follow specific rules.
Compliance and Governance: Applying organizational policies and compliance requirements automatically.

Setting Up a Kubernetes Admission Controller

Let’s set up a simple Validating Admission Webhook to understand the process. We’ll create a webhook to validate Pods, ensuring they have a specific label before being admitted to the cluster.

Step 1: Deploy a Webhook Server

First, you need a server that Kubernetes can call to validate objects. For this example, let’s assume you have a server running with an endpoint /validate that validates if incoming Pods have the label secure: "true".

Step 2: Create a TLS Certificate

Admission Webhooks require HTTPS endpoints with a valid TLS certificate signed by a CA that the Kubernetes API server trusts.

# Generate a self-signed certificate and key
openssl req -x509 -newkey rsa:4096 -sha256 -days 3650 -nodes \
  -keyout tls.key -out tls.crt -subj "/CN=admission-controller.default.svc"

Step 3: Create a Kubernetes Secret

Store the generated certificate and key as a secret in your Kubernetes cluster.

apiVersion: v1
kind: Secret
metadata:
  name: admission-tls
  namespace: default
data:
  tls.crt: $(base64 -w0 < tls.crt)
  tls.key: $(base64 -w0 < tls.key)

Step 4: Register the Admission Webhook

Define a ValidatingWebhookConfiguration that points to your webhook server.

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingWebhookConfiguration
metadata:
  name: example-validating-webhook
webhooks:
  - name: example.validator.local
    clientConfig:
      service:
        name: admission-controller
        namespace: default
        path: "/validate"
      caBundle: $(cat tls.crt | base64 | tr -d '\n')
    rules:
      - operations: ["CREATE"]
        apiGroups: [""]
        apiVersions: ["v1"]
        resources: ["pods"]
    admissionReviewVersions: ["v1"]
    sideEffects: None

Replace caBundle with the base64 encoded content of your tls.crt.

Step 5: Testing the Admission Controller

Deploy a Pod to your cluster and observe if it gets admitted based on the presence of the secure: "true" label.

apiVersion: v1
kind: Pod
metadata:
  name: test-pod
  labels:
    secure: "true"
spec:
  containers:
  - name: nginx
    image: nginx:1.14.2

Conclusion

Kubernetes Admission Controllers are a powerful feature for enhancing cluster security, enforcing policies, and ensuring compliance across all Kubernetes resources. By setting up your Admission Controller, you can take control of what gets deployed in your cluster, making your infrastructure more secure and reliable. Dive deeper into specific controllers and explore how they can help meet your organizational needs.

Comprehensive Guide: Deploying a Java App to Google Cloud Functions with gcloud

marocz — Fri, 19 Jan 2024 23:00:00 +0000

Introduction

Google Cloud Functions offers a serverless execution environment, perfect for running lightweight Java applications. This guide provides an end-to-end walkthrough on deploying a Java app to Google Cloud Functions, including detailed gcloud setup and function configuration.

Prerequisites

A Google Cloud account with billing enabled.
Basic knowledge of Java and Maven.

Step 1: Installing and Configuring gcloud

Before deploying your Java application, set up the Google Cloud SDK (gcloud) on your local machine.

Installing gcloud

Download the Google Cloud SDK installer for your operating system from the Google Cloud SDK page.
Follow the installation instructions specific to your OS.

Authenticating gcloud

After installation, authenticate gcloud and configure your project:

gcloud auth login

This command opens a new browser window asking you to log in with your Google credentials.

Setting the Default Project

Set your default project in gcloud:

gcloud config set project YOUR_PROJECT_ID

Replace YOUR_PROJECT_ID with your actual Google Cloud project ID.

Step 2: Setting Up Your Java Application

Create a basic Java function to deploy. This example uses Maven for building the application.

Creating a Simple Java Function

Create a new Maven project.
Add Google Cloud Functions dependency in your pom.xml:

<dependency>
  <groupId>com.google.cloud.functions</groupId>
  <artifactId>functions-framework-api</artifactId>
  <version>1.0.4</version>
</dependency>

Create a Java class implementing HttpFunction:

import com.google.cloud.functions.HttpFunction;
import com.google.cloud.functions.HttpRequest;
import com.google.cloud.functions.HttpResponse;
import java.io.BufferedWriter;

public class HelloWorld implements HttpFunction {
  @Override
  public void service(HttpRequest request, HttpResponse response)
      throws Exception {
    BufferedWriter writer = response.getWriter();
    writer.write("Hello World");
  }
}

Step 3: Configuring Your Cloud Function

Before deploying, you need to configure your Cloud Function in the Java project.

Defining the Function Handler

The entry point is the HelloWorld class. Ensure this class is correctly referenced in the deployment step.

Building the Deployment Artifact

Build your application into a deployable JAR file:

mvn clean package

Step 4: Deploying to Google Cloud Functions

Now, deploy your function using the gcloud CLI.

Deploying the Function

Deploy the function with the following command:

gcloud functions deploy hello-world-function \
  --entry-point HelloWorld \
  --runtime java11 \
  --trigger-http \
  --memory 512MB \
  --allow-unauthenticated

hello-world-function is your function's name.
'--entry-point' specifies the main class.
Other flags configure the runtime, trigger, memory, and authentication.

Verifying the Deployment

After deployment, gcloud will output the URL of your function. Test it by sending a request to this URL.

Conclusion

You've now successfully deployed a Java application to Google Cloud Functions using gcloud. This serverless solution is perfect for applications that require scalability and minimal infrastructure management. Experiment with more complex functions and integrate them with other Google Cloud services for advanced use cases.

Comprehensive Guide: Setting Up Cert-Manager on EKS, GKE, and AKS Using Terraform

marocz — Wed, 17 Jan 2024 23:00:00 +0000

Introduction

Managing SSL/TLS certificates in a Kubernetes environment can be challenging. Cert-manager simplifies this by automating the process of obtaining, renewing, and using those certificates. This post will guide you through setting up cert-manager on three major Kubernetes services: Amazon EKS, Google GKE, and Azure AKS using Terraform.

What is Cert-Manager?

Cert-manager is a Kubernetes add-on that automates the management and issuance of TLS certificates from various issuing sources such as Let’s Encrypt. It ensures certificates are valid and up to date, renewing them before they expire.

Why Use Cert-Manager with Terraform?

Automation: Terraform automates the deployment and configuration of cert-manager across different cloud providers.
Consistency: Ensures a consistent setup across various Kubernetes environments.
Infrastructure as Code: Leverage the benefits of defining your Kubernetes resources and cert-manager configuration as code.

Step-by-Step Setup

Common Prerequisites

Terraform installed on your local machine.
Access to an existing Kubernetes cluster on EKS, GKE, or AKS.
kubectl installed and configured for cluster access.

Step 1: Define the Terraform Variable for the Issuer Email

Add the following variable to your Terraform configuration. This variable will be used for the Cert-Manager cluster issuer's email.

variable "ISSUER_EMAIL" {
  type        = string
  description = "cert manager cluster issuer email"
}

Step 2: Deploy Cert-Manager Using Helm

Utilize the helm_release resource to deploy Cert-Manager into your EKS cluster:

resource "helm_release" "cert-manager" {
  name             = "cert-manager"
  repository       = "https://charts.jetstack.io"
  chart            = "cert-manager"
  version          = "v1.12.4"
  create_namespace = true
  namespace        = "cert-manager"
  cleanup_on_fail  = true

  set {
    name  = "installCRDs"
    value = true
  }
}

Step 3: Create a ClusterIssuer Resource

After deploying Cert-Manager, define a kubernetes_manifest resource for the ClusterIssuer, using the email variable:

resource "kubernetes_manifest" "clusterissuer_letsencrypt_prod" {
  depends_on = [
    helm_release.cert-manager
  ]
  manifest = {
    "apiVersion" = "cert-manager.io/v1"
    "kind" = "ClusterIssuer"
    "metadata" = {
      "name" = "letsencrypt-prod"
    }
    "spec" = {
      "acme" = {
        "email" = var.ISSUER_EMAIL
        "privateKeySecretRef" = {
          "name" = "letsencrypt-prod"
        }
        "server" = "https://acme-v02.api.letsencrypt.org/directory"
        "solvers" = [
          {
            "http01" = {
              "ingress" = {
                "class" = "nginx"
              }
            }
          }
        ]
      }
    }
  }
}

Setting up Cert-Manager on Azure AKS,EKS, GKE using Terraform

The steps for setting up Cert-Manager on Azure AKS,EKS or GKE are similar to above, with the main difference being the specific configurations and credentials for the respective clouds. Ensure you have the Azure provider configured in your Terraform setup.

Step 1: Define the Terraform Variable

Ensure the ISSUER_EMAIL variable is present in your Azure Terraform configuration.

Step 2: Deploy Cert-Manager and Create a ClusterIssuer

Follow the same steps as in the EKS setup. The Terraform code remains largely the same for deploying Cert-Manager and creating a ClusterIssuer in an AKS environment.

Step 3: Setting Up Providers and Backend

Before deploying Cert-Manager, configure your Terraform providers and backend. This configuration is crucial for managing the state of your resources and interacting with the cloud services.

For Google Cloud (GCP):

terraform {
  backend "gcs" {
    bucket      = "your-bucket-name"
    prefix      = "terraform/state"
    credentials = "path/to/credentials.json"
  }

  required_providers {
    google = {
      source  = "hashicorp/google"
      version = ">= 4.52.0"
    }
    kubernetes = {
      source  = "hashicorp/kubernetes"
      version = "= 2.17.0"
    }
    helm = {
      source  = "hashicorp/helm"
      version = "= 2.8.0"
    }
  }
}

provider "google" {
  project     = var.PROJECT_ID
  region      = var.REGION
  credentials = var.GCP_CRED
}

provider "google-beta" {
  project     = var.PROJECT_ID
  region      = var.REGION
  credentials = var.GCP_CRED
}

provider "kubernetes" {
  config_path = "~/.kube/config"
}

provider "helm" {
  kubernetes {
    config_path = "~/.kube/config"
  }
}

Conclusion

With Cert-Manager now set up in your Amazon EKS and Azure AKS clusters, you have automated the management of TLS certificates, ensuring secure communications within your Kubernetes environments. The power of Terraform allows you to replicate this setup across different environments and cloud providers, maintaining consistency and efficiency in your infrastructure management.

Integrating Trivy with GitLab CI, Azure DevOps, and GitHub Actions for Enhanced Security

marocz — Sun, 31 Dec 2023 23:00:00 +0000

Introduction

In the world of continuous integration and deployment (CI/CD), security is paramount. Trivy, a simple and comprehensive vulnerability scanner, is a key tool for scanning your applications and infrastructure for security issues. In this post, I'll discuss how to integrate Trivy into GitLab CI, Azure DevOps, and GitHub Actions, enhancing the security of your CI/CD pipelines.

Trivy: A Brief Overview

Trivy is an open-source vulnerability scanner for container images and filesystems. It's easy to integrate into CI/CD pipelines and provides comprehensive vulnerability detection.

Trivy is a comprehensive and easy-to-use vulnerability scanner designed for modern CI/CD pipelines. It specializes in scanning container images and filesystems for security vulnerabilities. Here are some key features that make Trivy stand out:

Wide Range of Vulnerability Detections: Trivy can detect vulnerabilities from various sources, including OS packages (Alpine, Red Hat, etc.) and application dependencies (NPM, RubyGems, etc.).
Simple Installation and Operation: Unlike other scanners that require pre-requisites or complex setup, Trivy is easy to install and can be run with a single command, making it ideal for integration into CI/CD pipelines.
High Accuracy: Trivy minimizes false positives and negatives, providing reliable and accurate scanning results. It regularly updates its vulnerability database to ensure it can detect the latest known vulnerabilities.
DevSecOps Friendly: Trivy fits perfectly in the DevSecOps model, allowing developers and security teams to work together. Its integration into CI/CD pipelines ensures that security is a shared responsibility and part of the daily workflow.
Comprehensive Reports: Trivy generates detailed and understandable reports, making it easier for developers to identify and address vulnerabilities.

Integrating Trivy with GitLab CI

GitLab CI/CD is a powerful platform for automating your software development process. To integrate Trivy with GitLab CI, follow these steps:

Create a .gitlab-ci.yml File
Start by creating a .gitlab-ci.yml file in your repository. This file defines your CI pipeline.
Add Trivy Scan Job
Within the .gitlab-ci.yml, define a job for Trivy scanning:

   trivy_scan:
     image: docker:latest
     services:
       - docker:dind
     script:
       - docker run --rm -v /var/run/docker.sock:/var/run/docker.sock -v $(pwd):/root aquasec/trivy:latest image <your_image_name>
     only:
       - master

Replace with the name of the Docker image you want to scan.

Integrating Trivy with Azure DevOps

For Azure DevOps users, integrating Trivy into your pipelines is straightforward.

Edit Your Azure Pipeline

In your Azure DevOps project, edit your pipeline YAML file.

Add Trivy Task

Add the following task to your pipeline:

- script: |
    docker run --rm -v /var/run/docker.sock:/var/run/docker.sock -v $(System.DefaultWorkingDirectory):/root aquasec/trivy:latest image <your_image_name>
  displayName: 'Run Trivy vulnerability scanner'

Again, replace with your Docker image name.

Integrating Trivy with GitHub Actions

GitHub Actions makes it easy to automate all your software workflows. To add Trivy scanning to a GitHub Actions workflow:

Create a Workflow File

In your repository, create a new file under .github/workflows/ (e.g., trivy-scan.yml).

Define the Trivy Scan Workflow

Use the following template for your workflow:

name: Trivy Scan

on:
  push:
    branches: [ master ]

jobs:
  trivy_scan:
    runs-on: ubuntu-latest

    steps:
    - name: Check out code
      uses: actions/checkout@v2

    - name: Run Trivy vulnerability scanner
      run: |
        docker run --rm -v /var/run/docker.sock:/var/run/docker.sock -v $(pwd):/root aquasec/trivy:latest image <your_image_name>

Modify to match your Docker image.

Conclusion

Integrating Trivy into your CI/CD pipelines is a crucial step in identifying and mitigating vulnerabilities early in the development process. Whether you're using GitLab CI, Azure DevOps, or GitHub Actions, adding Trivy ensures that your deployments are more secure and reliable. Stay vigilant and proactive in your approach to software security!

In-Depth Guide: Setting Up a NAT Gateway in AWS Using CloudFormation

marocz — Thu, 28 Dec 2023 16:26:44 +0000

Introduction

Managing network traffic and ensuring secure internet access for resources in AWS is a critical aspect of cloud architecture. A Network Address Translation (NAT) Gateway plays a pivotal role in this. In this comprehensive guide, we'll explore what a NAT Gateway is, its features, and step-by-step instructions on setting it up in AWS using CloudFormation.

What is a NAT Gateway?

A NAT (Network Address Translation) Gateway in AWS allows resources within a private subnet to access the internet or other AWS services, while preventing the Internet from initiating a connection with those resources. It's used to provide internet traffic to EC2 instances in a private subnet in a secure manner.

Key Features of NAT Gateway

Security: It allows instances in a private subnet to initiate outbound IPv4 traffic to the internet, while not allowing inbound traffic from the internet.
High Availability: AWS NAT Gateway is designed to be highly available within an Availability Zone.
Bandwidth Scaling: Automatically scales its bandwidth up to 45 Gbps without any manual intervention.
No Need for Patching: Being a managed service, it does not require any patch management.

Prerequisites

An AWS account
Basic knowledge of AWS VPC, subnets, and CloudFormation

Step-by-Step Setup Using CloudFormation

Step 1: Understanding the Architecture

The architecture involves a VPC with both public and private subnets. The NAT Gateway is placed in the public subnet, providing outbound internet access to instances in the private subnet.

Step 2: Writing the CloudFormation Template

Create a file named nat-gateway.yaml. This CloudFormation script creates the necessary components:

VPC (MyVPC): This acts as the networking backbone.
Subnets (PublicSubnet and PrivateSubnet): For segregating resources. The NAT Gateway resides in the public subnet.
Internet Gateway (InternetGateway): To provide access to the internet for the public subnet.
Elastic IP (NatGatewayEIP): A static IPv4 address used by the NAT Gateway for sending traffic.
NAT Gateway (NatGateway): The managed NAT service.
Route Tables and Associations: To route traffic appropriately from the private subnet to the NAT Gateway and from the public subnet to the internet.

AWSTemplateFormatVersion: '2010-09-09'
Description: 'CloudFormation Template for NAT Gateway Setup'

Resources:
  MyVPC:
    Type: AWS::EC2::VPC
    Properties:
      CidrBlock: 10.0.0.0/16
      EnableDnsSupport: true
      EnableDnsHostnames: true

  PublicSubnet:
    Type: AWS::EC2::Subnet
    Properties:
      VpcId: !Ref MyVPC
      CidrBlock: 10.0.1.0/24
      MapPublicIpOnLaunch: true

  PrivateSubnet:
    Type: AWS::EC2::Subnet
    Properties:
      VpcId: !Ref MyVPC
      CidrBlock: 10.0.2.0/24

  InternetGateway:
    Type: AWS::EC2::InternetGateway

  AttachGateway:
    Type: AWS::EC2::VPCGatewayAttachment
    Properties:
      VpcId: !Ref MyVPC
      InternetGatewayId: !Ref InternetGateway

  NatGatewayEIP:
    Type: AWS::EC2::EIP
    DependsOn: AttachGateway
    Properties:
      Domain: vpc

  NatGateway:
    Type: AWS::EC2::NatGateway
    Properties:
      AllocationId: !GetAtt NatGatewayEIP.AllocationId
      SubnetId: !Ref PublicSubnet

  RouteTable:
    Type: AWS::EC2::RouteTable
    Properties:
      VpcId: !Ref MyVPC

  PublicRoute:
    Type: AWS::EC2::Route
    DependsOn: AttachGateway
    Properties:
      RouteTableId: !Ref RouteTable
      DestinationCidrBlock: 0.0.0.0/0
      GatewayId: !Ref InternetGateway

  PrivateRoute:
    Type: AWS::EC2::Route
    DependsOn: NatGateway
    Properties:
      RouteTableId: !Ref RouteTable
      DestinationCidrBlock: 0.0.0.0/0
      NatGatewayId: !Ref NatGateway

  AssociatePublicSubnet:
    Type: AWS::EC2::SubnetRouteTableAssociation
    Properties:
      SubnetId: !Ref PublicSubnet
      RouteTableId: !Ref RouteTable

  AssociatePrivateSubnet:
    Type: AWS::EC2::SubnetRouteTableAssociation
    Properties:
      SubnetId: !Ref PrivateSubnet
      RouteTableId: !Ref RouteTable

Step 3: Deploying the Template

To deploy this template, navigate to the AWS CloudFormation console, choose 'Create stack', and upload the nat-gateway.yaml file. Follow the prompts to create the stack. You can also use the AWS CLI to deploy the stack.

aws cloudformation create-stack --stack-name my-nat-gateway --template-body file://nat-gateway.yaml

Conclusion

You have successfully created a NAT Gateway in your AWS environment using CloudFormation. This setup will enable your instances in a private subnet to securely access the internet while maintaining the security and privacy of your resources. The power of CloudFormation allows you to easily replicate this setup in different environments or regions, ensuring consistency and efficiency in your cloud infrastructure.

Deploying SentinelOne Agent to EKS Using Terraform

marocz — Sat, 28 Oct 2023 20:41:06 +0000

A step-by-step guide to deploy SentinelOne Agent and S1 Helper to your EKS cluster using Terraform.

Introduction

When it comes to managing and securing Kubernetes clusters, having the right set of tools is crucial. SentinelOne, a cybersecurity solution, provides an agent that helps in monitoring and protecting your EKS (Elastic Kubernetes Service) cluster. In this guide, I will walk you through the process of deploying the SentinelOne Agent and S1 Helper to your EKS cluster using Terraform, which will provide an automated and reproducible deployment.

Prerequisites

An AWS account and an EKS cluster up and running.
Terraform installed on your local machine.
SentinelOne account with necessary credentials.

Step 1: Preparing Your Terraform Environment

Before we dive into the Terraform code, ensure you have your AWS credentials configured properly. You can set up your credentials using the AWS CLI or by configuring environment variables.

export AWS_ACCESS_KEY_ID="your-access-key-id"
export AWS_SECRET_ACCESS_KEY="your-secret-access-key"
export AWS_DEFAULT_REGION="your-region"

Step 2: Setting Up Terraform Configuration

Create a file named main.tf and add the following Terraform configuration to define your provider and the required resources.

provider "aws" {
  region = "us-west-2"  # Change to your AWS region
}

provider "kubernetes" {
  config_path = "~/.kube/config"
}

resource "kubernetes_namespace" "s1" {
  metadata {
    name = "sentinelone"
  }
}

resource "kubernetes_deployment" "s1_agent" {
  metadata {
    name      = "s1-agent"
    namespace = kubernetes_namespace.s1.metadata[0].name
  }

  spec {
    replicas = 3

    selector {
      match_labels = {
        app = "s1-agent"
      }
    }

    template {
      metadata {
        labels = {
          app = "s1-agent"
        }
      }

      spec {
        container {
          image = "sentinelone/agent:latest"  # Replace with the correct image
          name  = "s1-agent"

          env {
            name  = "S1_API_TOKEN"
            value = "your-s1-api-token"
          }
        }
      }
    }
  }
}

Step 3: Deploying S1 Helper

The S1 Helper is a crucial component that assists in the management of the SentinelOne Agent. Add the following to your main.tf:

resource "kubernetes_deployment" "s1_helper" {
  metadata {
    name      = "s1-helper"
    namespace = kubernetes_namespace.s1.metadata[0].name
  }

  spec {
    replicas = 1

    selector {
      match_labels = {
        app = "s1-helper"
      }
    }

    template {
      metadata {
        labels = {
          app = "s1-helper"
        }
      }

      spec {
        container {
          image = "sentinelone/helper:latest"  # Replace with the correct image
          name  = "s1-helper"

          env {
            name  = "S1_API_TOKEN"
            value = "your-s1-api-token"
          }
        }
      }
    }
  }
}

Step 4: Applying Your Configuration

With your configuration ready, initialize Terraform and apply your configuration:

terraform init
terraform apply

Conclusion

You've now automated the deployment of SentinelOne Agent and S1 Helper to your EKS cluster using Terraform. This setup not only enhances the security posture of your cluster but also provides a streamlined and reproducible deployment process. Feel free to tweak the Terraform configurations to meet your specific use case and security requirements.

Caching Content with AWS CloudFront: A Detailed Guide

marocz — Sat, 14 Oct 2023 23:29:52 +0000

Hello, Community!

Today, we're exploring the acceleration of web content delivery using AWS CloudFront.
Additionally, we'll delve into automating this setup with Terraform, ensuring you have an efficient, replicable, and maintainable infrastructure.

Understanding AWS CloudFront

AWS CloudFront is a content delivery network (CDN) service that securely delivers data, videos, applications, and APIs to customers globally with low latency and high transfer speeds. CloudFront is integrated with AWS – both physical locations that are directly connected to the AWS global infrastructure, as well as other AWS services.

Edge Locations: CloudFront caches copies of your content in edge locations across the globe ensuring fast delivery to users.
Origin Fetches: When content is not cached, CloudFront fetches it from specified origins, like S3 buckets or HTTP servers.
Content Delivery: CloudFront provides a secure and optimized delivery of your content to users via HTTPS.
Invalidation: You can remove cached content to refresh it with updated versions.
Customization: Customize content delivery by configuring cache behaviors, geo-restrictions, and more.
Integration: Seamlessly integrate CloudFront with other AWS services like AWS WAF, AWS Shield, and Lambda@Edge for enhanced security and functionality.

Benefits:

Performance: Reduced latency due to proximity-based content delivery.
Scalability: Smooth handling of traffic spikes.
Integration: Compatibility with other AWS services like Amazon S3, EC2, and Lambda.
Security: Features HTTPS, AWS WAF integration, and DDoS protection.

CloudFront Cache Invalidation

If you update your content and want to remove the old content from CloudFront edge locations, you need to create an invalidation.

Go to the Distribution.
Invalidations tab → Create Invalidation.
Enter the path for the content to invalidate (e.g., /images/*).

Setting Up CloudFront Manually

Prerequisites:

An AWS account.
Content to distribute, e.g., a website on S3 or EC2.

Procedure:

Login to the AWS Management Console.
Go to CloudFront.
Click Create Distribution and choose Web.
Configure Distribution:
- Origin Settings: Define where CloudFront fetches content.
- Default Cache Behavior Settings: Set policies, like redirecting HTTP to HTTPS.
- Distribution Settings: Define price class, logging, SSL, etc.
Click Create Distribution. Upon creation, you'll receive a unique CloudFront URL.
Testing: Access content via the CloudFront URL to verify.

Setting Up AWS CloudFront using AWS CLI

Create an S3 Bucket:

aws s3api create-bucket --bucket my-bucket-name --region us-west-2

Configure CloudFront Distribution:

Navigate to CloudFront in the AWS Management Console.
Select 'Create Distribution'.
Choose 'Web' and specify your S3 bucket as the origin.

aws cloudfront create-distribution \
--origin-domain-name my-bucket-name.s3.amazonaws.com

Set Cache Behavior:
- Choose suitable caching rules under 'Cache Behavior Settings'.

aws cloudfront create-distribution \
--default-cache-behavior AllowedMethods=GET,HEAD

Automating Setup with Terraform

Prerequisites:

Terraform installed and configured.
AWS CLI set up with the necessary permissions.

Procedure using Terraform:

Initialize Configuration

provider "aws" {
  region = "us-west-1"
}

Define S3 Bucket

resource "aws_s3_bucket" "b" {
  bucket = "my-tf-test-bucket"
  acl    = "private"
}

Define CloudFront Distribution

resource "aws_cloudfront_distribution" "s3_distribution" {
  origin {
    domain_name = aws_s3_bucket.b.bucket_regional_domain_name
    origin_id   = "S3-BUCKET-ORIGIN-ID"

    s3_origin_config {
      origin_access_identity = "origin-access-identity/cloudfront/ID_GOES_HERE"
    }
  }

  enabled             = true
  is_ipv6_enabled     = true
  default_root_object = "index.html"

  default_cache_behavior {
    allowed_methods  = ["DELETE", "GET", "HEAD", "OPTIONS", "PATCH", "POST", "PUT"]
    cached_methods   = ["GET", "HEAD"]
    target_origin_id = "S3-BUCKET-ORIGIN-ID"

    forwarded_values {
      query_string = false

      cookies {
        forward = "none"
      }
    }

    viewer_protocol_policy = "allow-all"
    min_ttl                = 0
    default_ttl            = 3600
    max_ttl                = 86400
  }

  price_class = "PriceClass_100"

  restrictions {
    geo_restriction {
      restriction_type = "none"
    }
  }

  viewer_certificate {
    cloudfront_default_certificate = true
  }
}

Deploy

terraform init to initialize.
terraform plan to preview.
terraform apply to deploy.

Conclusion:
AWS CloudFront is a powerful tool to cache and deliver content efficiently. By creating an S3 bucket, configuring a CloudFront distribution, and setting up cache behaviors, you can significantly accelerate content delivery to end-users.

Best Practices

Use CloudFront with S3 Origin Access Identity to restrict direct bucket access.
Enable Gzip compression for optimized data transfer.
Employ Lambda@Edge for advanced content handling.
Implement asset versioning to reduce the need for cache invalidations.

Conclusion

Pairing AWS CloudFront with Terraform offers both speed in content delivery and efficiency in infrastructure management. Whether serving small sites or global apps, this combo ensures swift, secure content delivery. Happy caching! 🚀

My Journey Upgrading GitLab and GitLab Runner on AWS EC2

marocz — Sun, 08 Oct 2023 19:13:06 +0000

Introduction

Recently, I embarked on the journey of upgrading our GitLab server and GitLab Runner hosted on an AWS EC2 instance. Though the process is documented, there's nothing like hands-on experience to understand the nuances. In this article, I'll share my step-by-step approach, the challenges I faced, and the commands that saved my day!

📦 Prerequisites:

An EC2 instance with GitLab already humming along.
A GitLab runner, tirelessly building and testing our projects.
Trusty SSH access to the EC2 instance.

🛡️ Step 1: Backing Up Data

Before diving into the upgrade, I made sure to backup. Can't stress this enough!

GitLab:

sudo gitlab-rake gitlab:backup:create

GitLab Runner:

Backing up the runner configuration was a breeze:

cp /etc/gitlab-runner/config.toml ~/gitlab-runner-config-backup.toml

🚀 Step 2: Upgrading the GitLab Server:

Checking Available Versions:
My curiosity led me to check which versions were available:

sudo yum list available gitlab-ce --showduplicates | sort -r

Updating Repository Information:

Ensuring I had the latest repository info was crucial:

https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.rpm.sh | sudo bash

The Actual Upgrade:

Choosing the desired version, I proceeded:

sudo yum install gitlab-ce-<version_number>

Verification:
Post-upgrade, I had to ensure everything was in order:

sudo gitlab-rake gitlab:env:info

🏃 Step 3: Upgrading the GitLab Runner:

Repository Update:
A quick refresh of the repository information:

curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.rpm.sh | sudo bash

Runner Upgrade:
With a leap of faith:

sudo yum install gitlab-runner

🔍 Step 4: Verifying the GitLab Runner Upgrade:

I made sure the runner was back on its feet:

sudo gitlab-runner restart
sudo gitlab-runner status

🚒 Step 5: Potential Rollback:

Though everything went smoothly, I was prepared for a rollback:

GitLab:

sudo gitlab-rake gitlab:backup:restore BACKUP=<backup timestamp>

GitLab Runner:

cp ~/gitlab-runner-config-backup.toml /etc/gitlab-runner/config.toml
sudo gitlab-runner restart

🌟 Conclusion:

My adventure upgrading GitLab and GitLab Runner on AWS EC2 was both challenging and rewarding. While the process is generally straightforward, it's the small nuances that make the experience unique.

To all the DevOps enthusiasts out there, always backup, stay updated, and happy coding!

My Journey with AWS LocalStack and Terraform: A Local AWS Environment Setup

marocz — Fri, 29 Sep 2023 08:15:53 +0000

Introduction

In the realm of cloud computing, gaining hands-on experience is pivotal. However, it can sometimes be expensive or complex to do this on real AWS environments. That's where AWS LocalStack paired with Terraform comes into the picture. This setup allows you to mock AWS resources locally, providing a cost-effective and straightforward way to test your cloud applications. In this post, I'll share how I set up a local AWS environment using Terraform and LocalStack to manage resources like S3, EC2, and ECR.

Prerequisites

AWS CLI
Docker
Terraform
LocalStack

Step 1: Installing LocalStack

Ensure Docker is running on your machine, then install LocalStack using pip:



pip install localstack

Certainly! Below is your post formatted according to the Dev.to markdown styling:

```markdown

---

## Step 2: Configuring LocalStack

Create a </span>docker-compose.yaml<span class="sb"> file with the following content to configure the services you'll need:



version: '</span>3.1<span class="s1">'
services:
  localstack:
    image: localstack/localstack
    ports:
      - "4566:4566"
      - "4571:4571"
    environment:
      - SERVICES=s3,ec2,ecr
      - DEBUG=1
      - DATA_DIR=/tmp/localstack/data
    volumes:
      - "./tmp/localstack:/tmp/localstack"


</span></code></pre></div><h2>
  <a name="step-3-launching-localstack" href="#step-3-launching-localstack">
  </a>
  Step 3: Launching LocalStack
</h2>

<p>To launch LocalStack, run the following command:</p>
<div class="highlight"><pre class="highlight shell"><code>

docker-compose up


</code></pre></div><h2>
  <a name="step-4-prepping-terraform" href="#step-4-prepping-terraform">
  </a>
  Step 4: Prepping Terraform
</h2>

<p>Construct a <code>main.tf</code> file with the subsequent content to establish the AWS resources using Terraform:</p>
<div class="highlight"><pre class="highlight hcl"><code>

<span class="nx">provider</span> <span class="s2">"aws"</span> <span class="p">{</span>
  <span class="nx">endpoints</span> <span class="p">{</span>
    <span class="nx">s3</span>      <span class="p">=</span> <span class="s2">"http://localhost:4566"</span>
    <span class="nx">ec2</span>     <span class="p">=</span> <span class="s2">"http://localhost:4566"</span>
    <span class="nx">ecr</span>     <span class="p">=</span> <span class="s2">"http://localhost:4566"</span>
  <span class="p">}</span>
  <span class="nx">region</span>                      <span class="p">=</span> <span class="s2">"us-east-1"</span>
  <span class="nx">skip_credentials_validation</span> <span class="p">=</span> <span class="kc">true</span>
  <span class="nx">skip_metadata_api_check</span>     <span class="p">=</span> <span class="kc">true</span>
  <span class="nx">skip_requesting_account_id</span>  <span class="p">=</span> <span class="kc">true</span>
<span class="p">}</span>

<span class="nx">resource</span> <span class="s2">"aws_s3_bucket"</span> <span class="s2">"my_bucket"</span> <span class="p">{</span>
  <span class="nx">bucket</span> <span class="p">=</span> <span class="s2">"my-bucket"</span>
<span class="p">}</span>

<span class="nx">resource</span> <span class="s2">"aws_ec2_instance"</span> <span class="s2">"my_instance"</span> <span class="p">{</span>
  <span class="nx">ami</span>           <span class="p">=</span> <span class="s2">"ami-abcdef01"</span>
  <span class="nx">instance_type</span> <span class="p">=</span> <span class="s2">"t2.micro"</span>
<span class="p">}</span>

<span class="nx">resource</span> <span class="s2">"aws_ecr_repository"</span> <span class="s2">"my_repo"</span> <span class="p">{</span>
  <span class="nx">name</span> <span class="p">=</span> <span class="s2">"my-repo"</span>
<span class="p">}</span>


</code></pre></div><h2>
  <a name="step-5-applying-terraform-configuration" href="#step-5-applying-terraform-configuration">
  </a>
  Step 5: Applying Terraform Configuration
</h2>

<p>Now, initialize Terraform and apply the configuration:</p>
<div class="highlight"><pre class="highlight shell"><code>

terraform init
terraform apply


</code></pre></div><h2>
  <a name="conclusion" href="#conclusion">
  </a>
  Conclusion
</h2>

<p>This setup has become a part of my daily workflow, enabling me to test and develop cloud applications locally with ease. </p>

<p>The amalgamation of Terraform and LocalStack provides a robust platform to mock AWS resources, significantly smoothing the development and testing phases. </p>

<p>Feel free to adapt this setup to your needs and explore other AWS resources available in LocalStack. Happy coding!</p>

<p><em>Note: Ensure you replace placeholder values like "ami-abcdef01" and "my-bucket" with your specific values or references.</em></p>

<p><img src="https://dev-to-uploads.s3.amazonaws.com/uploads/articles/9qgk3c3g5c8c85mwtslb.jpeg" alt="Image description"></p>

Title: How to Spin Up an AWS EKS Cluster Using Terraform

marocz — Mon, 11 Sep 2023 10:01:36 +0000

Introduction:

Elastic Kubernetes Service (EKS) is Amazon's managed Kubernetes solution that makes it easier to run Kubernetes on AWS without managing the underlying infrastructure. In this post, we'll walk through the process of deploying an EKS cluster using Terraform.

Prerequisites:

An AWS account
AWS CLI installed and configured
Terraform installed
kubectl installed

Step 1: Set up Terraform:

Before you can use Terraform to create resources in AWS, ensure you've set it up correctly:

$ terraform init

Sure! Here's a basic outline and content for a Dev.to post on creating an AWS EKS Cluster using Terraform:

Title: How to Spin Up an AWS EKS Cluster Using Terraform

Introduction:
Elastic Kubernetes Service (EKS) is Amazon's managed Kubernetes solution that makes it easier to run Kubernetes on AWS without managing the underlying infrastructure. In this post, we'll walk through the process of deploying an EKS cluster using Terraform.

Prerequisites:

An AWS account
AWS CLI installed and configured
Terraform installed
kubectl installed

Step 1: Set up Terraform:

Before you can use Terraform to create resources in AWS, ensure you've set it up correctly:

$ terraform init

Step 2: Define Your Infrastructure:

Create a file named eks-cluster.tf and define your AWS provider and EKS resources:

provider "aws" {
  region = "us-west-2"
}

module "eks" {
  source          = "terraform-aws-modules/eks/aws"
  cluster_name    = "my-cluster"
  cluster_version = "1.20"
  subnets         = ["subnet-abcde012", "subnet-bcde012a", "subnet-cde012ab"]

  node_groups = {
    eks_nodes = {
      desired_capacity = 2
      max_capacity     = 3
      min_capacity     = 1

      instance_type = "m5.large"
      key_name      = var.key_name
    }
  }
}

Step 3: Initialize and Apply:

$ terraform init
$ terraform apply

After running the terraform apply command, Terraform will show you the changes it plans to make and ask for confirmation. If everything looks good, type yes.

Sure! Here's a basic outline and content for a Dev.to post on creating an AWS EKS Cluster using Terraform:

Title: How to Spin Up an AWS EKS Cluster Using Terraform

Prerequisites:

An AWS account
AWS CLI installed and configured
Terraform installed
kubectl installed

Step 1: Set up Terraform:
Before you can use Terraform to create resources in AWS, ensure you've set it up correctly:

$ terraform init

Step 2: Define Your Infrastructure:

Create a file named eks-cluster.tf and define your AWS provider and EKS resources:

provider "aws" {
  region = "us-west-2"
}

module "eks" {
  source          = "terraform-aws-modules/eks/aws"
  cluster_name    = "my-cluster"
  cluster_version = "1.20"
  subnets         = ["subnet-abcde012", "subnet-bcde012a", "subnet-cde012ab"]

  node_groups = {
    eks_nodes = {
      desired_capacity = 2
      max_capacity     = 3
      min_capacity     = 1

      instance_type = "m5.large"
      key_name      = var.key_name
    }
  }
}

Step 3: Initialize and Apply:

$ terraform init
$ terraform apply

After running the terraform apply command, Terraform will show you the changes it plans to make and ask for confirmation. If everything looks good, type yes.

Step 4: Configure kubectl:
Once your EKS cluster is up, you need to configure kubectl:

$ aws eks --region us-west-2 update-kubeconfig --name my-cluster

Step 5: Verify:

$ kubectl get nodes

Conclusion:

Using Terraform, you can easily deploy an EKS cluster and manage its lifecycle. This method is repeatable, version-controlled, and can be extended with more advanced features and configurations.

DEV Community: marocz

Automating EKS Deployment and NGINX Setup Using Helm with AWS CDK in Python

Introduction

Prerequisites

Step 1: Bootstrap Your CDK Project

Step 2:

Understanding the AWS CDK Initialization Process

How to Structure Your CDK Project

Creating a Construct

Creating a Stack

Running cdk synth and What to Expect

Step 2: Define Your EKS Cluster in CDK

Step 3: Add NGINX Ingress Using Helm

Step 4: Deploy Your CDK Stack

Step 5: Verify the NGINX Deployment

Adding Unit Tests to Your AWS CDK Project

Setting Up Your Testing Environment

Writing Unit Tests

Running Your Tests

Conclusion on Unit Testing

Conclusion

Building Container Images Securely on AWS EKS with Kaniko

Introduction

What is Kaniko?

Why Use Kaniko on AWS EKS?

Setting Up Kaniko on AWS EKS

Prerequisites

Step 1: Create an ECR Repository

Step 2: Configure IAM Permissions

Find Your EKS Node IAM Role

Attach the IAM Policy to the EKS Node Role

Verifying the Policy Attachment

Step 3: Prepare Your Kubernetes Cluster

Step 4: Deploy Kaniko Pod

Step 5: Verify the Image Build and Push

Additional Method: Running Kaniko Inside a Docker Container

Step 1: Pull the Kaniko Executor Image

Step 2: Prepare Your Build Context and Dockerfile

Step 3: Run Kaniko in Docker

Step 4: Authenticate Docker with ECR

Step 5: Verify the Image in ECR

Combining the Best of Both Worlds

Conclusion

Mastering Kubernetes Admission Controllers: Setup and Use Cases

Introduction

What are Kubernetes Admission Controllers?

Types of Admission Controllers

Why Use Admission Controllers?

Setting Up a Kubernetes Admission Controller

Step 1: Deploy a Webhook Server

Step 2: Create a TLS Certificate

Step 3: Create a Kubernetes Secret

Step 4: Register the Admission Webhook

Step 5: Testing the Admission Controller

Conclusion

Comprehensive Guide: Deploying a Java App to Google Cloud Functions with gcloud

Introduction

Prerequisites

Step 1: Installing and Configuring gcloud

Installing gcloud

Authenticating gcloud

Setting the Default Project

Step 2: Setting Up Your Java Application

Creating a Simple Java Function

Step 3: Configuring Your Cloud Function

Defining the Function Handler

Building the Deployment Artifact

Step 4: Deploying to Google Cloud Functions

Deploying the Function

Verifying the Deployment

Conclusion

Comprehensive Guide: Setting Up Cert-Manager on EKS, GKE, and AKS Using Terraform

Introduction

What is Cert-Manager?

Why Use Cert-Manager with Terraform?

Step-by-Step Setup

Common Prerequisites

Step 1: Define the Terraform Variable for the Issuer Email

Step 2: Deploy Cert-Manager Using Helm

Step 3: Create a ClusterIssuer Resource

Running `cdk synth` and What to Expect