But Kubernetes networking has been evolving rapidly.

Recently, the Kubernetes community has been shifting focus toward the Gateway API, which is designed to be the next-generation replacement for the traditional Ingress model. Because of this shift, the community is gradually deprecating the ingress-nginx controller in favor of more modern networking approaches built around Gateway API.

For teams running workloads on Google Kubernetes Engine (GKE), this transition becomes even more relevant since GKE provides native support for Gateway API with managed load balancing.

If you're currently running applications using NGINX Ingress, this guide will help you understand why the shift is happening and how to transition to Gateway API in GKE.

By the end of this tutorial, you’ll have a working Gateway + HTTPRoute setup that replaces your traditional ingress-based routing.

Why Move Away from Ingress NGINX?

While Ingress NGINX has been a widely used solution for exposing Kubernetes services, the ecosystem is gradually shifting toward the Gateway API as the long-term standard for traffic management.

Some of the major limitations of traditional Ingress include:

• Limited routing capabilities

• Complex annotations

• Lack of role separation between platform teams and app teams

• Poor extensibility

Gateway API solves these problems by introducing a more structured and modular networking model.

Understanding Gateway API Architecture

Gateway API introduces several new Kubernetes resources that separate responsibilities clearly.

This model allows platform teams to manage infrastructure while application teams manage routing rules.

Prerequisites

Before starting the migration, ensure you have:

• A running GKE cluster

• kubectl installed

• gcloud CLI configured

• Permissions to manage cluster networking

Verify cluster connectivity:

kubectl get nodes

Enable Gateway API in GKE

Gateway API support must be enabled in your GKE cluster.

You can do this either through the GKE Console or Terraform, depending on how you manage infrastructure.

Option 1: Enable via GKE Console

1. Open Google Cloud Console

2. Navigate to Kubernetes Engine → Clusters

3. Select your cluster

4. Go to Details

5. Enable Gateway API

Option 2: Enable Gateway API Using Terraform

If you're managing infrastructure using Terraform, you can enable the Gateway API during cluster creation.

resource "google_container_cluster" "gke_cluster" {
  name     = "gateway-demo-cluster"
  location = "us-central1"

  gateway_api_config {
    channel = "CHANNEL_STANDARD"
  }
}

Apply the configuration:

terraform apply

List Available GatewayClasses

Once Gateway API is enabled, GKE automatically installs supported GatewayClasses.

List them using:

kubectl get gatewayclass

Example output:

NAME                                       CONTROLLER                            
gke-l7-global-external-managed             networking.gke.io/gateway                   
gke-l7-gxlb                                networking.gke.io/gateway            
gke-l7-regional-external-managed           networking.gke.io/gateway                    
gke-l7-rilb                                networking.gke.io/gateway                                         

Each GatewayClass corresponds to a specific load balancing capability.

For most public applications, we will typically use:

gke-l7-global-external-managed

Create the Gateway (Application Gateway)

Now we create the Gateway resource that acts as the entry point to your cluster.

Create a file called gateway.yaml

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: application-gateway
spec:
  gatewayClassName: gke-l7-global-external-managed
  listeners:
  - name: http
    protocol: HTTP
    port: 80
    allowedRoutes:
      namespaces:
        from: All

Apply it:

kubectl apply -f gateway.yaml

Verify:

kubectl get gateway

CLI output:

kubectl get gateway

Deploy Application

Let’s deploy a sample nginx application to simulate a typical service behind an ingress.

Deployment:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx
        ports:
        - containerPort: 80

Service:

apiVersion: v1
kind: Service
metadata:
  name: nginx-service
spec:
  selector:
    app: nginx
  ports:
  - port: 80
    targetPort: 80

Apply:

kubectl apply -f deployment.yaml
kubectl apply -f service.yaml

Create an HTTPRoute

Now we connect the application-gateway to the backend service using HTTPRoute.

Create httproute.yaml

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: nginx-route
spec:
  parentRefs:
  - name: application-gateway
  rules:
  - backendRefs:
    - name: nginx-service
      port: 80

Apply it:

kubectl apply -f httproute.yaml

Verify:

kubectl get httproute

Architecture flow:

Gateway API architecture in GKE

Access the Application

Retrieve the Gateway external IP:

kubectl get gateway application-gateway

Open the IP in your browser.

You should see:

This confirms your Gateway API configuration is working successfully.

Troubleshooting Tips

If your application isn't accessible, Perform these checks:

To check Gateway status:

kubectl describe gateway application-gateway

To check HTTPRoute status:

kubectl describe httproute nginx-route

To get Pod health:

kubectl get pods

Most issues occur due to incorrect service references or missing GatewayClass.

Key Takeaways

Migrating from Ingress NGINX to Gateway API in GKE provides several advantages:

• Modern Kubernetes networking standard

• More powerful routing capabilities

• Clear separation between infrastructure and application routing

• Native integration with GKE load balancers

Gateway API is expected to become the primary way to manage traffic in Kubernetes clusters going forward.

💡Do not treat migration as a simple YAML conversion ... treat it as a networking architecture upgrade.

Conclusion

Gateway API represents the next generation of Kubernetes traffic management. It provides:

• Clear separation of responsibilities

• Rich routing capabilities

• Extensible policy framework

• Better security model

Migrating from Ingress NGINX to Gateway API requires planning, but by following progressive migration, policy standardization, and observability best practices, teams can modernize their Kubernetes networking stack safely.

When I’m working with an S3 + CloudFront setup, I noticed something that made me curious there are two different ways to let CloudFront access S3: OAI (Origin Access Identity) and the newer OAC (Origin Access Control).

That got me wondering:

Why are there two options? What’s the real difference?

To answer that, I decided to run a hands-on experiment and explore both approaches in detail.

Now that I’ve done it, I’m sharing my experience below including what I built, what I learned, and how you can try it too.

If you've ever been confused about when to use which or how they actually work in practice this post is for you!

🤔 Wait, Why Are There Two Options Anyway?

At first glance, both OAI and OAC let CloudFront access private S3 content securely so naturally, I wondered:

If both are doing the same thing, why did AWS introduce a new method?

Here’s the thing: both OAI and OAC are used to let CloudFront securely access content from an S3 bucket. So, you might think: “If the end result is the same, why is AWS pushing everyone toward OAC now?”

Let me break it down for you:

🔍 The Problem with Legacy OAI

With OAI, we create a special identity, and we update our S3 bucket policy to allow that OAI to access the bucket. Then, CloudFront uses that identity to fetch content from S3.

Seems straightforward, right?

But here’s the issue:
Any CloudFront distribution using that same OAI can access the bucket.

So, imagine I use the same OAI for multiple CloudFront distributions now, all of them can read from that S3 bucket. There's no way to limit it to just one CloudFront distribution.

🎯 That’s a security gap.

🔐 Enter OAC (Origin Access Control)

To address this issue, AWS introduced OAC.

With OAC, we create an access control configuration and assign it per CloudFront distribution. Then, in the S3 bucket policy, we don’t just allow based on a shared OAI… instead, we use a condition like AWS:SourceArn to only allow that exact CloudFront distribution to access the S3 content.

So now, only one specific CloudFront distribution and no others can read from the bucket. That’s a huge win for security and best practices. 🚀

❓But wait… Why Can’t We Just Use SourceArn with OAI?

I had the same question at first!

The problem is: OAI doesn’t include the CloudFront distribution’s identity when making the request to S3.

It only signs the request using the OAI credentials, but there's no way for S3 to know which distribution is calling. That means even if you try to use AWS:SourceArn in the bucket policy, it won’t work with OAI because the request lacks that source context.

👉 OAC solves this by including the distribution’s ARN in the signature, allowing S3 to enforce precise, per-distribution policies.

So, while OAI gives S3 a kind of generic identity, OAC brings full context and secure granularity.

🛠️ What I Built

Okay now I believe you understand the difference theoretically.
But let’s be real: theory alone isn’t enough.

So how do we actually see this difference in action?

No worries I got you! 😎

I wrote a Terraform script that will let you spin up a hands-on environment in seconds.

Here’s what it does:

Scenario 1 – Using OAI (Legacy)

• Creates one S3 bucket with a test file.

• Creates two CloudFront distributions (A & B) using the same OAI.

• The S3 bucket policy allows access to that OAI.

• Result: both distributions can access the S3 content, even though we didn’t restrict them individually and that’s the core issue with OAI.

Scenario 2 – Using OAC (Modern Approach)

• Same S3 bucket and test file.

• Creates two new CloudFront distributions (C & D) using OAC.

• The bucket policy uses AWS:SourceArn to allow access only from CloudFront distribution C.

• This means:
  ✅ CloudFront C can access the S3 content
  ❌ CloudFront D cannot, because it's not explicitly allowed in the S3 bucket policy.

• Result: Now we have tight access control only the specified distributions can access the content.

🤯 What I Learned

✅ OAI (Origin Access Identity)

• Simple and familiar.

• Bucket policy just checks the OAI ARN.

• BUT: you can't restrict it to a specific distribution, so if you share the same OAI with multiple CloudFront distributions, all of them get access.

This was clear when I spun up two distributions (A and B) both could access the S3 content, even though the bucket policy didn’t mention their individual ARNs.

✅ OAC (Origin Access Control)

• Modern approach supports sigv4 signing.

• You must use origin_access_control_id in CloudFront.

• The S3 policy can now restrict access to a specific CloudFront distribution using AWS:SourceArn.

When I enabled OAC, only the distributions C and D were created. The S3 bucket policy now allow the specific distribution can access its content.

🧪 Try It Yourself

I have written all the Terraform code you need, also included clear instructions in the GitHub README. so, you can spin up the full environment in just a few commands.

👉 Repository URL:
🔗 gerlynm/just-curious

📌 Final Thoughts

If you're building something new go with OAC. It’s more secure and future ready. But OAI still works.

Hope this helps someone trying to understand the differences through actual practice, just like I did. Let me know if you’d like the full Terraform code or a breakdown of the policy structures!

Happy experimenting! ✨

Using that information, I successfully configured ExternalDNS to update records across AWS accounts. If you're facing a similar challenge, this blog will save you time by providing a direct, step-by-step solution.

Prerequisites: ✅

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

• Two AWS Accounts:

  • Account A: This is where your Route 53 hosted zone resides.

  • Account B: This will host your EKS cluster and where ExternalDNS will run.

• Tools Configured: Aws cli, Kubectl , lens (optional), Ingress controller (optional to check with ingress)

• Route53 (Account A): You should have your DNS hosted zone already setup in Account A.

• 

• EKS Cluster (Account B): You need a running EKS cluster in Account B that ExternalDNS will interact with.

• 

High-Level Overview: 💡

Here is a quick rundown of the steps I'll be taking:

1. Create an IAM Role in the Route 53 Account (Account A): This role will grant necessary Route 53 permissions and trust the IAM role we will create for ExternalDNS in Account B.

2. Create an IAM Role in the EKS Account (Account B): This role will have the permission to assume the IAM role we created in Account A. We will configure its trust policy to trust your OIDC provider associated with your EKS cluster.

3. Install ExternalDNS in your EKS Cluster (Account B): We will use Addons to install ExternalDNS with custom configuration values that leverage the cross-account IAM roles.

4. Verification: We will verify the setup by deploying application by pointing hostname.

Let's get started! 🚀

1. Create the IAM Role in the Route 53 Account (Account A): 1️⃣

In your Account A, navigate to the IAM console and follow these steps:

• Click on Roles in the left-hand navigation pane.

• Click Create role.

• For the "Select type of trusted entity," choose AWS account.

• 

• Enter the Account ID of Account B.

• Click Next. (ignore other options)

• Now, we need to attach permissions for Route 53. Search for and select the AmazonRoute53FullAccess policy.

• 

• • Important Security Consideration: For production environments, it's highly recommended to scope down these permissions to the minimum required for ExternalDNS to function.

• Click Next.

• Give your role a descriptive name (e.g., Route53ExternalDNSAccess).

• Review the role details and click Create role.

Take note of the ARN (Amazon Resource Name) of this newly created role. You'll need it in the next step. It will look something like: arn:aws:iam::ACCOUNT_A_ID:role/Route53ExternalDNSAccess.

2. Create the IAM Role in the EKS Account (Account B): 2️⃣

Now, switch to your Account B and follow these steps in the IAM console:

• Click on Roles.

• Click Create role.

• For the "Select type of trusted entity," choose Web identity (OIDC).

• 

• For the "Identity provider," select the OIDC provider associated with your EKS cluster. You can find this information in your EKS cluster details under the "Overview" tab. It will typically look like oidc.eks.REGION.amazonaws.com/id/YOUR_OIDC_ID.

• 

• For the "Audience," enter sts.amazonaws.com.

• Then click Add Condition to provide service account and external DNS namespace to give access

  

• Before creating role, we need to add permissions that allow this role to assume the role we created in Account A.

• So, for that open policy console in new tab and click Create policy.

• In the JSON tab of the "Create policy" page, paste the following policy, replacing
  arn:aws:iam::<ACCOUNT_A_ID>:role/Route53ExternalDNSAccess with the actual ARN of the role you created in Account A:

•       {
            "Statement": [
                {
                    "Action": [
                        "sts:AssumeRole"
                    ],
                    "Effect": "Allow",
                    "Resource": [
                        "arn:aws:iam::<ACCOUNT_A_ID>:role/Route53ExternalDNSAccess" #arn of route53 role which we created above.
                    ],
                    "Sid": "Statement1"
                }
            ],
            "Version": "2012-10-17"
        }
  

• Click Next

• Give your policy a descriptive name (e.g., ExternalDNSAssumeRoute53RolePolicy).

• Click Create policy.

• Go back to the "Create role" page (where you selected the OIDC trust). Click Next: Permissions.

• Search for and select the policy you just created (ExternalDNSAssumeRoute53RolePolicy).

• 

• Click Next: Review.

• Give your role a descriptive name (e.g., ExternalDNSIRSAccess).

• Review the role details and click Create role.

Take note of the ARN of this newly created role. You'll need this for the Route53ExternalDNSAccess Role (Account A) to assume this. It will look something like: arn:aws:iam::ACCOUNT_B_ID:role/ExternalDNSIRSAccess.

3. Install ExternalDNS with Configuration Values 🔻

(Account B):

• Now, in your Account B, use Addons to install ExternalDNS.

• Click Next

• Now add the role which we have created under IRSA option

• To pass the below configuration to the external DNS, expand the Optional configuration settings option.

•       domainFilters:
          - nginx.local
        txtOwnerId: Z03011653ICHPFH5D6TUJ
        extraArgs:
          - --aws-zone-type=private
          - --aws-assume-role=arn:aws:iam::<ACCOUNT_A_ID>:role/Route53ExternalDNSAccess
  

• 

Once you have configured the values, you can install ExternalDNS using Addons

4.Verification: 🍾

After the ExternalDNS is deployed, you can check the ExternalDNS pod logs in your EKS cluster (Account B) using kubectl logs -n kube-system -l app=external-dns. Look for any errors related to IAM permissions or Route 53 connectivity.

To verify that ExternalDNS is correctly creating DNS records, you can deploy a sample application and create an Ingress resource with a hostname. Here are example Kubernetes manifests:

Deployment (deploy.yaml):

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx
          image: nginx:latest
          ports:
            - containerPort: 80
          resources:
            requests:
              cpu: 100m
              memory: 128Mi
            limits:
              cpu: 200m
              memory: 256Mi

Service (service.yaml):

apiVersion: v1
kind: Service
metadata:
  name: nginx-service
  labels:
    app: nginx
spec:
  type: ClusterIP 
  selector:
    app: nginx
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80

Ingress (ingress.yaml):

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: nginx-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  ingressClassName: nginx 
  rules:
    - host: test.nginx.local
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: nginx-service
                port:
                  number: 80

• Replace test.nginx.local with a hostname that matches the domainFilters you configured for ExternalDNS (e.g., if your domainFilters is nginx.local).

Apply these manifests to your EKS cluster:

kubectl apply -f nginx.yaml
kubectl apply -f nginx-service.yaml
kubectl apply -f nginx-ingress.yaml

After the Ingress is created, ExternalDNS should automatically create your records in your Route 53 hosted zone (in Account A) pointing test.nginx.local to the load balancer associated with your Ingress.

This is how it looks.

Conclusion: ⭐

Setting up ExternalDNS with cross-account Route 53 felt daunting at first for me, but now you can easily setup by following these precise steps, you can save yourself a significant amount of time and get your DNS records managed seamlessly across your AWS accounts. Remember to always adhere to the principle of least privilege when granting IAM permissions in production environments.

I hope this guide has been helpful! ❤️Let me know in the comments if you have any questions or run into any issues. Happy Automating! 🥳

Step 1: Create and Attach an IAM Role to the EC2 Instance 🍳

• Navigate to the AWS IAM Console and go to Roles.

• Click Create role.

• Select AWS Service and choose EC2, then click Next.

  

• In the permissions section, search for and attach the following policy:

  • AmazonSSMManagedInstanceCore (required for SSM agent to communicate with AWS Systems Manager)

    

• Click Next, give the role a name (e.g., SSMManagedEC2), and create the role.

  

• Attach the IAM role to your EC2 instance:

  • Go to the EC2 Console > Select your instance

  • Click Actions > Security > Modify IAM Role

  • Select the IAM role you created and click Update IAM Role

    

Step 2: Verify SSM Agent is Installed and Running ✅

📌 Check out for SSM agent Verification details: AWS Systems Manager

For Ubuntu, run the following command to check if the agent is installed:

sudo systemctl status snap.amazon-ssm-agent.amazon-ssm-agent.service

📌 If the agent is not installed, then refer this link for installation: Manually installing and uninstalling SSM Agent

Step 3: Access EC2 Instance Using SSM 🚀

Now you can access your EC2 instance using SSM through the AWS Console or AWS CLI.

Option 1: Using the AWS Console 💻

1. Navigate to AWS Systems Manager Console.

2. Click the EC2 instance you want to access.

3. Click Connect.

   

4. Click Session Manager and then Connect to open a shell session.

Option 2: Using AWS CLI ⚡

To access EC2 via the local terminal or AWS CLI, install the SSM Agent on your local machine using the following commands:

curl "https://s3.amazonaws.com/session-manager-downloads/plugin/latest/ubuntu_64bit/session-manager-plugin.deb" -o "session-manager-plugin.deb"
sudo dpkg -i session-manager-plugin.deb

For other OS versions, refer to the SSM Plugin Installation.

Run the following command to enter an EC2 machine via SSM through the terminal. 🥳

aws ssm start-session --target <instance-id>

📌 Make sure your AWS CLI is configured with the right permissions and region settings.

Conclusion 🎃

Enabling SSM Connect in EC2 instances enhances security, eliminates the need for SSH keys, and simplifies instance management. By following these steps, you can securely manage your AWS environment with AWS Systems Managers “Session Manager”.

📬Do you have any questions or need further assistance? Leave a comment below or explore my other AWS tutorials for more cloud management tips!

Step 1: Create a Manual Snapshot of the RDS Instance 📸

1. Go to the RDS Dashboard in the source AWS account.

2. Select the RDS instance you want to migrate.

3. Click Actions > Take Snapshot.

   

4. Provide a name for the snapshot and confirm.

   

   Note: Creating a snapshot may take some time, depending on the size of your database.

Step 2: Share the Snapshot with the Destination AWS Account ⏩

1. Once the snapshot is created, go to the Snapshots section in the RDS Dashboard.

   

2. Select the snapshot you just created.

3. Click Actions > Share Snapshot.

   

4. Enter the AWS Account ID of the destination account.

   

5. Click Save to share the snapshot.

Step 3: Copy the Snapshot to the Destination Account ☕

1. Log in to the destination AWS account.

2. Go to the RDS Dashboard > Snapshots.

3. Look for the shared snapshot in Shared with Me section.

   

4. Select the snapshot and click Actions > Copy Snapshot.

   

5. Choose the destination region (if different) and provide a name for the copied snapshot.

   

6. Click Copy Snapshot.

   

   Note: Copying the snapshot may take some time, depending on the size of the database and the region.

Step 4: Restore the RDS Instance in the Destination Account 🔁🗺️

1. Once the snapshot is copied, select it and click Actions > Restore Snapshot.

   

2. Configure the new RDS instance:

   • Set the DB identifier name.

   • Set the DB instance size, storage type, and other settings.

   • Configure networking (VPC, subnet group, security group).

     

3. Click Restore DB Instance.

   Note: The restored RDS instance will have the same data as the original database but will be a new instance in the destination account.

Step 5: Verify and Clean Up ✅🧹

1. Verify the New RDS Instance:

   • Log in to the new RDS instance and ensure all data and configurations are correct.

   • Test the connection to the database from your application or client tools.

     

2. Clean Up:

   • Delete the shared snapshot from the source account if it’s no longer needed.

   • Terminate the original RDS instance in the source account (if no longer required).

Important Considerations: 🛑‼️

1. Downtime:

   • During the migration, the original RDS instance remains operational. However, any changes made to the database after the snapshot was taken will not be included in the migrated instance. Plan accordingly to minimize data loss.

2. Automated Backups:

   • If automated backups are enabled for the RDS instance, ensure you have a recent backup before starting the migration.

3. IAM Permissions:

   • Ensure both AWS accounts have the necessary IAM permissions to share and access snapshots.

4. Cross-Region Migration:

   • If you’re migrating the RDS instance to a different region, you’ll need to copy the snapshot to the new region before restoring it.

5. Encryption:

   • If your RDS instance is encrypted, ensure the destination account has access to the encryption key (KMS key). You may need to share or recreate the key in the destination account.

Pro Tip: 🚀

If you want to minimize downtime or migrate a live database, you can use AWS Database Migration Service (DMS). DMS allows you to replicate data from the source RDS instance to the destination RDS instance in near real-time. This approach is more complex but ideal for large databases or zero-downtime migrations.

Conclusion: 🎃

Migrating an RDS database to another AWS account is straightforward if you follow the snapshot and sharing process. While it requires some planning, the steps are simple and ensure your data remains intact. For more advanced use cases, consider using AWS DMS for a seamless migration.

📬Need help with your RDS migration? Drop a comment below or reach out for more tips on managing your AWS resources! 🚀

Step 1: Share the S3 Bucket with the Destination Account ⚙️

📌 AWS doesn’t let you “move” a bucket directly, but you can share it and copy its contents.
Here’s how:

1. Go to the S3 Console in the source account.

2. Select the bucket you want to migrate.

3. Click the Permissions tab

   

4. Add a bucket policy to grant access to the destination account by adding the below policy.

    {
      "Version": "2012-10-17",
      "Statement": [
        {
          "Effect": "Allow",
          "Principal": {
            "AWS": "arn:aws:iam::DESTINATION_ACCOUNT_ID:root"
          },
          "Action": [
            "s3:ListBucket",
            "s3:GetObject"
          ],
          "Resource": [
            "arn:aws:s3:::SOURCE_BUCKET_NAME",
            "arn:aws:s3:::SOURCE_BUCKET_NAME/*"
          ]
        }
      ]
    }
   

   Replace DESTINATION_ACCOUNT_ID and SOURCE_BUCKET_NAME with your details.

   

5. Save the policy. Now, the destination account can access the bucket.

Step 2: Copy the Bucket Contents to the Destination Account ☕🗺️

Once shared, copy the data to a new bucket in the destination account.

1. Log in to the destination account and create a new bucket.

2. Use the AWS CLI to copy the files: (Use destination account credentials)

    aws s3 sync s3://SOURCE_BUCKET_NAME s3://DESTINATION_BUCKET_NAME
   

   Expected Output:

   

Step 3: Verify the Data ✅

After copying, check the data in the destination bucket:

• Confirm the file count and size match the source.

• Open a few files to ensure they’re intact.

• If the bucket has versioning, verify all versions were copied.

  

Pro Tips: 🚀

• Use AWS Datasync for large buckets to speed up transfers.

• Enable versioning in the destination bucket if the source has it.

• Test the process with a small bucket before migrating critical data.

Conclusion: 🎃

Migrating an S3 bucket to another AWS account is simple when you know the steps. Share the bucket, copy the data, verify, and done! Follow this guide, and you’ll have your S3 bucket migrated in no time.

📬Found this guide helpful? Share it with your team or drop a comment below with your questions. For more AWS tips, subscribe and stay tuned!

#getintokube #getintokubeblogs

Step 1: Stop the EC2 Instance 🫸🛑

The first step is to stop the EC2 instance in the source account. Why?

• Stopping the instance ensures that all data is written to the disk, and no ongoing processes are modifying the filesystem. This guarantees a consistent snapshot.

• It reduces the risk of corruption or missing data in the AMI (Amazon Machine Image).

How I Did It:

1. Logged into the source AWS account.

2. Navigated to the EC2 Dashboard.

3. Selected the instance I wanted to migrate.

4. Clicked Instance State > Stop Instance.

   

Step 2: Create an AMI Image 📸

Once the instance is stopped, the next step is to create an AMI (Amazon Machine Image). An AMI is a template that contains the information required to launch an instance, including the root volume, permissions, and configurations.

How I Did It:

1. Selected the stopped instance in the EC2 Dashboard.

2. Clicked Actions > Image and Templates > Create Image.

   

3. Filled in the details:

   • Name: Gave the AMI a meaningful name.

   • Description: Added a brief description for future reference.

   • Unticked the "Reboot" option to ensure the instance stayed stopped.

     

4. Clicked Create Image.

Step 3: Wait for the AMI to Become Available⚙️

Creating an AMI can take a few minutes, depending on the size of the instance. Wait for the AMI to reach the "Available" state in the AMIs section of the EC2 Dashboard.

Step 4: Share the AMI with the Destination Account ⏩

Once the AMI is available, the next step is to share it with the destination AWS account. This allows the destination account to access and use the AMI.

How I Did It:

1. Went to the AMIs section in the EC2 Dashboard.

2. Selected the AMI I just created.

3. Clicked Actions > Modify AMI Permissions.

   

4. Added the AWS Account ID of the destination account.

   

5. Clicked Save Changes.

   

Step 5: Verify the AMI in the Destination Account ✅

After sharing the AMI, I switched to the destination AWS account to verify that the AMI was successfully shared.

How I Did It:

1. Logged into the destination AWS account.

2. Navigated to the AMIs section in the EC2 Dashboard.

3. Looked for the shared AMI in the Private image section.

   

Success! The AMI was visible in the destination account, ready to be used.

Step 6: Copy the AMI to the Destination Account ☕

To ensure the AMI is fully available in the destination account, I copied it. This step is especially important if the source and destination accounts are in different AWS regions.

How I Did It:

1. Selected the shared AMI in the destination account.

2. Clicked Actions > Copy AMI.

   

3. Chose the destination region and provided a name for the copied AMI.

   

4. Clicked Copy AMI.

Step 7: Launch the Instance from the AMI 🚀

Finally, it was time to launch the EC2 instance in the destination account using the copied AMI.

How I Did It:

1. Selected the copied AMI in the AMIs section.

2. Clicked Actions > Launch Instance.

   

3. Configured the instance settings:

   • Instance Type: Chose the appropriate instance type.

   • Network Settings: Selected the VPC, subnet, and security group.

   • Key Pair: Associated a key pair for SSH access.

     

4. Clicked Launch Instance.

Step 8: Verify and celebrate! ✅🥳

Once the instance was launched, I logged in to verify that everything was working as expected. I checked:

• Applications: Were they running correctly?

• Data: Was all the data intact?

• Configurations: Were the settings preserved?

  

Boom! The migration was successful, and the instance was up and running in the destination account.

Pro Tips for a Smooth Migration: 🚀

1. Test the Process: Before migrating a critical instance, test the process with a non-essential instance to ensure everything works.

2. Monitor Costs: Keep an eye on data transfer and storage costs during the migration.

3. Clean Up: After the migration, delete the AMI and snapshots from the source account to avoid unnecessary charges.

Conclusion: 🎃

Migrating an EC2 instance to another AWS account doesn’t have to be complicated. By following these steps stopping the instance, creating an AMI, sharing it, and launching it in the destination account you can ensure a smooth and hassle-free migration.

📌So, what are you waiting for? Start migrating your EC2 instances today and take control of your AWS infrastructure!

📬Found this guide helpful? Share it with your team or leave a comment below if you have any questions. Don’t forget to follow for more AWS tips and tricks!

#ec2 #aws #ec2migration # devops #cloud #getintokube #getintokubeblogs

My Scenario: 😵‍💫

When I deployed my application using AWS CloudFront, I could only point my domain to www.example.com. Whenever I tried to access example.com (the root domain), I got Error from GoDaddy. This is because GoDaddy doesn’t support CNAME records for APEX (root) domains by default. CNAME records are typically used for subdomains like www, but not for the root domain.

The Solution: Using GoDaddy’s Forwarding Option💡

After some research and trial and error, I found a simple workaround using GoDaddy’s forwarding feature. Here’s how I did it:

1. Log in to Your GoDaddy Account: Go to your GoDaddy dashboard and navigate to the domain you want to configure.

2. Set Up a Forward:

   • Go to the Forwarding section.

     

   • Select the root domain (example.com) and set it to forward to www.example.com.

   • Choose the Permanent (301) forward option.

   • Then click > Save.

     

3. Save the Changes: Once you’ve configured the forward, save the changes. It might take a few minutes for the changes to propagate.

Why This Works: ⚒️✅

By setting up a forward, you’re essentially telling GoDaddy to forward all traffic from example.com to www.example.com. Since www.example.com is a subdomain, you can easily point it to your CloudFront distribution using a CNAME record. This way, users accessing example.com will be seamlessly forwarded to www.example.com, where your application is hosted.

Steps to Point www.example.com to CloudFront: 🧱🔨

1. Go to DNS Management: In your GoDaddy account, navigate to the DNS management section for your domain.

2. Add a CNAME Record:

   • Create a new CNAME record for www.

   • Point it to your CloudFront distribution’s domain name (e.g., d1234.cloudfront.net).

     

3. Save the Changes: Save the DNS changes and wait for them to propagate (this can take up to 48 hours, but it’s usually faster).

Conclusion: 🎃

While GoDaddy doesn’t allow CNAME records for APEX (root) domains, this simple forward workaround ensures that your users can access your application using both example.com and www.example.com. By following these steps, I was able to solve the issue and make my application accessible from both URLs.

I hope this guide helps you too! ❤️

Pro Tip: 🚀

📌If you’re looking for a more advanced solution, consider using AWS Route 53 for DNS management. Route 53 supports ALIAS records, which allow you to point your root domain directly to CloudFront without the need of forwarding option.

📌Alternatively, if you don’t want to use AWS, you can use Cloudflare. Cloudflare allows you to create CNAME-like records for root domains (using their CNAME flattening feature), making it easy to point example.com directly to your CloudFront endpoint. Plus, Cloudflare offers additional benefits like improved performance, security, and DDoS protection.

📬Let me know in the comments if this solution worked for you! and 🔗share this guide with others who might find it helpful!

#cloudfront #aws #getintokube #getintokubeblogs

Pre-requisites

1. AWS CLI Installed and Configured:

   • Install AWS CLI v2 or later if you haven’t already.

   • Ensure your CLI is configured with the correct region and credentials (aws configure).

2. IAM Permissions:

   • Add SSM permissions to the Task IAM role:

   • You should add the following policy to your existing ECS task IAM role. This grants permission for the ECS task to connect with the SSM Session Manager service.

     

   • Click ecsTaskExecutionRole > Add Permission > Create inline policy > Switch to JSON > Paste the below policy then save. Do this for both the policies.

       {
          "Version": "2012-10-17",
          "Statement": [
              {
              "Effect": "Allow",
              "Action": [
                   "ssmmessages:CreateControlChannel",
                   "ssmmessages:CreateDataChannel",
                   "ssmmessages:OpenControlChannel",
                   "ssmmessages:OpenDataChannel"
              ],
             "Resource": "*"
             }
          ]
       }
     

   • Add ECS Execute Command permission to your Task IAM role:

     Make sure your IAM role contains a policy that allows the action ecs:ExecuteCommand. Otherwise, you’re not able to run aws ecs execute-command in the AWS CLI in order to access the running container.

   • ✍️ Alter “Resource” value with ECS cluster arn in the below policy⬇️.

       {
         "Version": "2012-10-17",
         "Statement": [
           {
             "Effect": "Allow",
             "Action": "ecs:ExecuteCommand",
             "Resource": "arn:aws:ecs:example-region:example-arn:cluster/example-cluster/*"
           }
         ]
       }
     

3. AWS Session Manager Plugin Installed:

   • Install the Session Manager Plugin for AWS CLI.

Steps to Execute into a Container

1. Identify Your Cluster and Task

• Find the ECS cluster name and the task running your container:

    aws ecs list-clusters
  

    aws ecs list-tasks --cluster <your-cluster-name>
  

2. Describe the Task

• Get details about the task, including the container name:

    aws ecs describe-tasks --cluster <your-cluster-name> --tasks <task-id>
  

3. Enable Execute Command on the Task

• Now you need to enable the ECS Exec feature on existing ECS service and deploy the new task by using the below command.

    aws ecs update-service \
        --cluster <cluster-name> \
        --task-definition <task-definition-name> \
        --service <service-name> \
        --enable-execute-command \
        --force-new-deployment
  

• After executing the above command, wait for the new task to deploy successfully.

4. Execute the Command

• To open an interactive shell inside the container, replace /bin/bash with /bin/sh if bash is not available in your container.

    aws ecs execute-command --cluster <cluster-name> \
        --task <task-id> \
        --container <container-name> \
        --interactive \
        --command "/bin/sh"
  

• This is the output you’ll see when you’re executing aws ecs execute-command on an actual running container.

    aws ecs execute-command --cluster <cluster-name> \
        --task <task-id> \
        --container <container-name> \
        --interactive \
        --command "/bin/sh"
  
    The Session Manager plugin was installed successfully. Use the AWS CLI to start a session.
  
    Starting session with SessionId: ecs-execute-command-5tap5jrfpg8g5p2o5z8opsfqxe
    #
  

By following these steps, you can 🤩 successfully enable and use the ECS Exec feature to open an interactive shell inside a running container.

If you have any suggestions, ideas, or thoughts to add, feel free to drop them in the comments. 👇📩

Your feedback means a lot! Don’t forget to hit that like❤️ button to show your support and stay tuned for more content. 🔔

⭐Thanks again!

#ecs #aws #ecs_fargate #getintokube #getintokube_blogs #aws #ecs #ecs_fargate #How_to_Enter_into_ AWS_Fargate_Container #How_to_exec_into_AWS_Fargate_Container

📌Resources: https://github.com/gerlynm/java-deployment.git

Create EKS cluster using eksctl

At first, we can start with creating EKS cluster using eksctl. It will take up to 10 to 15 minutes of time for provisioning resources.

eksctl create cluster --name java-eks-cluster --region ap-south-1  --nodegroup-name java-eks-nodes --node-type t2.micro --nodes 2 --profile magic

While waiting for the resource to be created, we can create Dockerfile for our java application.

Create Docker file for Java application

You can change the Dockerfile as per your requirement.

# Create the image using a distroless base image
FROM gcr.io/distroless/java17-debian11

# Set the working directory
WORKDIR /app

# Copy the JAR file from the build stage
COPY /target/*.jar ./java.jar

# Expose the port the application runs on
EXPOSE 8080

# Run the application
ENTRYPOINT ["java", "-jar", "java.jar"]

• Using base image as distroless image because it has only the necessary runtime libraries and no package manager or shell, also we can be able to reduce image size by using this.

• WORKDIR sets the working directory inside the container to /app.

• COPY it copies the JAR file from our local target directory into the container.

• EXPOSE this command informs container listens on port 8080, and it doesn’t publish the port.

• ENTRYPOINT it runs the Java application using the java -jar command, specifying the java.jar file that was copied earlier.

Create Helm charts

• Helm charts are package manager for Kubernetes environment, also we can simply create manifest files without typing manually.

• Using the below command to create a sample helm chart and we can alter it as per our requirement.

helm create java-api-charts

• Depending upon the project requirement we need to modify the helm charts templates.

• In our case we are going to modify some files like services.yaml, deployments.yaml, values.yml

Below I have mentioned code snippets what are the changes needs to make in each file.

deployment.yaml

ports:
  - name: http
    containerPort: {{ .Values.service.targetPort }}
    protocol: TCP

service.yaml

ports:
    - port: {{ .Values.service.port }}
      targetPort: {{ .Values.service.targetPort }}
      protocol: TCP
      name: http

values.yaml

image:
  repository: <aws-account-id>.dkr.ecr.ap-south-1.amazonaws.com/<repo-name>
  # This sets the pull policy for images.
  pullPolicy: IfNotPresent
  # Overrides the image tag whose default is the chart appVersion.
  tag: "latest"

service:
  # This sets the service type more information can be found here: https://kubernetes.io/docs/concepts/services-networking/service/#publishing-services-service-types
  type: ClusterIP
  # This sets the ports more information can be found here: https://kubernetes.io/docs/concepts/services-networking/service/#field-spec-ports
  port: 80
  targetPort: 8080

ingress:
  enabled: true
  className: "nginx"
  annotations: 
    nginx.ingress.kubernetes.io/rewrite-target: /
    # kubernetes.io/ingress.class: nginx
    # kubernetes.io/tls-acme: "true"
  hosts:
    - host: rest-java-api.local
      paths:
        - path: /
          pathType: Prefix

livenessProbe:
  httpGet:
    path: /hello-world
    port: 8080
readinessProbe:
  httpGet:
    path: /hello-world
    port: 8080

Create ECR in AWS

To avoid clicky clicky…... Just create ECR repository by using below command

aws ecr create-repository --repository-name rest-java-api --profile magic

Install Nginx Ingress Controller (NLB)

This command will install the nginx ingress controller in the cluster and creates a Network Load balancer in our AWS account.

kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v1.12.0-beta.0/deploy/static/provider/aws/deploy.yaml

📌 NLB (Network Load Balancer) doesn’t natively handle HTTP/HTTPS

But You can still route HTTP/HTTPS traffic by configuring the NLB to forward the traffic to your instances, which can be handled by an ingress controller (like NGINX) running within your Kubernetes cluster.

Install ArgoCD in EKS cluster

Using below command can be able to install ArgoCD in our EKS cluster.

kubectl create namespace argocd
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

To access the ArgoCD UI

They are multiple ways to access ArgoCD UI, here we are using simplest way

kubectl get svc -n argocd #look for service named "argocd-server" 
kubectl port-forward svc/argocd-server 8080:443 -n argocd

(Optional) To run kubectl port-forward command in background use below command

#To run the process
nohup kubectl port-forward svc/argocd-server 8080:443 -n argocd &
tail -f nohup.out

#To kill the process
ps aux | grep 'kubectl port-forward'
kill <PID>

For Login into the argoCD UI

• Get the secrets of argocd namespace.

• Then edit the secret named argocd-initial-admin-secret to view the secret. Copy that.

• By default, that copied password is encoded with base64, so to decode that password use the below base64 command.

    kubectl get secrets -n argocd
    kubectl edit secrets argocd-initial-admin-secret  -n argocd
    echo <password> | base64 --decode
  

• Now provide the credentials in the login page. The default username is admin

Create GitHub Actions workflow

This is our GitHub Actions workflow for our Java application

1. Configure the triggers (main, master, dev etc…)

2. Choose the working Directory

3. Configure Java and build the application using Maven.

4. Configures AWS credentials.

5. Logs in to Amazon ECR (Elastic Container Registry).

6. Builds a Docker image and pushes it to ECR.

name: Java CI with Maven and Dockerized it then push it to AWS ECR

on:
  push:
    branches: [ "master" ]
  pull_request:
    branches: [ "master" ]

jobs:
  build:
    runs-on: ubuntu-latest
    defaults:
      run:
        working-directory: 01-hello-world-rest-api
    steps:
    - uses: actions/checkout@v4
    - name: Set up JDK 17
      uses: actions/setup-java@v4
      with:
        java-version: '17'
        distribution: 'temurin'
        cache: maven

    - name: Build with Maven
      run: mvn clean package -DskipTests

    - name: Configure AWS Credentials
      uses: aws-actions/configure-aws-credentials@v1
      with:
        aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
        aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
        aws-region: ap-south-1

    - name: Login to Amazon ECR
      id: login-ecr
      uses: aws-actions/amazon-ecr-login@v1

    - name: Build, tag, and push docker image to Amazon ECR
      env:
        REGISTRY: ${{ steps.login-ecr.outputs.registry }}
        REPOSITORY: ${{ secrets.AWS_ECR }}
        IMAGE_TAG: latest
      run: |
        docker build -t $REGISTRY/$REPOSITORY:$IMAGE_TAG .
        docker push $REGISTRY/$REPOSITORY:$IMAGE_TAG

Add the AWS Credentials and ECR repository name as secrets on the repository secrets.

Create ArgoCD application

• Click on NEW APP button > provide Application Name, Project Name, Sync Policy, GitHub Repository, Path.

• Then click Create button.

Application Deployed!

• Within couple of seconds our argoCD application will sync up with our repository and deploy the application.

• From the below image we can see all objects are in healthy state.

Access the Application via CLI

As we configured the local domain (rest-java-api.local) in ingress. The load balancer listens on that particular domain name.

To access using local domain follow the steps below

host <loadbalancer-dns-name>

Using host command, we can get the Ip address of the load balancer.

Then using the below command with the load balancer Ip address can get the desired output.

# Replace 13.200.151.192 with your load balancer ip address
curl -H "Host: rest-java-api.local" 13.200.151.192/hello-world

This command will send a request to http://13.200.151.192/hello-world with the Host header set to rest-java-api.local.

In simple terms, this command sends a request to a specific IP address but tells the server it's trying to reach a specific domain.

Here you can see the Hello World output from our application.

Access the Application via UI

To access the application using UI we need to setup the DNS mapping for our local domain name.

I have already written docs on how to step up DNS mapping, follow those steps and browse this URL: rest-java-api.local/hello-world

📌 In Realtime scenarios we would use valid domain name like google.com, amazon.com, so above step not required in Realtime Projects.

Clean Up the Resources

To delete all the resources created for this project use the below command.

Delete the EKS cluster

eksctl delete cluster --name eks-cluster --region ap-south-1 --profile magic

Delete ECR Repository

 aws ecr delete-repository --repository-name rest-java-api  --force --profile magic

Thanks for sticking with me until the end! 😊

I hope you found this project valuable and worth your time. If you have any suggestions, ideas, or thoughts to add, feel free to drop them in the comments. 👇📩

Your feedback means a lot! Don’t forget to hit that like ❤️ button to show your support and stay tuned for more content. 🔔

⭐Thanks again!

#getintokube #getintokubeblogs

PHP runs on the server rather than the client’s browser because PHP interprets the .php code into HTML and send it to the client’s browser.

⭐ Other client-side languages like javascript run in the user’s browser.

How does PHP work?

1. Client Request: When a user requests a PHP webpage, that browser sends a request to the web server.

2. Web Server Processes Request: The web server (like Apache or Nginx) receives the request and recognizes that it’s a required PHP webpage. Then it hands over the file to the PHP interpreter.

3. PHP Interpreter Executes Code: The PHP interpreter processes the PHP code within the PHP file.

4. Generate HTML: After processing the PHP file, it generates HTML (or other web-compatible output) as the response content.

5. Send Response to Browser: The web server sends the generated HTML back to the client's browser, which renders the content.

Use of Dependency Manager?

Dependency manager is an important tool that helps us manage libraries and packages required for our PHP application.

There are multiple Dependency managers but the most widely used dependency manager for PHP is Composer.

• Composer makes it simple to manage our project's dependencies through a single composer.json file.

• You can add dependencies using the composer command:

composer require monolog/monolog

This command updates the composer.json file and installs the package.

• To install the dependencies listed in composer.json

composer install

• To update all dependencies to their latest versions

composer update

Example for composer.json file

{
    "name": "my-php-project",
    "description": "A simple PHP project.",
    "require": {
        "monolog/monolog": "2.3.0",
        "guzzlehttp/guzzle": "^7.0" 
    }
}

Logging:

• PHP applications typically use logging libraries like Monolog, Built-in error_log() function, Log to a Database or Laravel Logging (if using Laravel).

• Using these tools, we can set up robust logging mechanisms for our PHP application, making it easier to monitor and debug our application.

Environment variables:

• In PHP, configuration settings are typically placed in a file named config.php. But nowadays environment-specific configurations are kept in a .env file for managing environment variables.

• Especially for applications coded with frameworks such as Laravel, the configuration settings of such applications like ports, and database connection strings are stored using this .env.

  Example:

DB_HOST=localhost
DB_USERNAME=root
DB_PASSWORD=password
DB_NAME=example_db
APP_DEBUG=true 
APP_URL=http://example.com

Containerizing the PHP application:

1. Use the official PHP 8.0 image installed with the Apache web server.

2. Set the working directory in the container to /var/www

3. Install PHP extensions required by the application.

4. Copy the files into the container directory.

5. Enables the Apache mod_rewrite module, commonly used for URL rewriting in PHP applications.

6. This line indicates that the application will listen on port 9000. This does not publish the port.

7. This command runs Apache in the foreground to keep the container running.

# Use the official PHP image as a parent image
FROM php:8.0-apache    

# Set working directory
WORKDIR /var/www

# Install PHP extensions
RUN docker-php-ext-install pdo_mysql mbstring exif pcntl bcmath gd

# Copy application files
COPY . /var/www

# Enable Apache modules
RUN a2enmod rewrite

# Expose port 9000 
EXPOSE 9000

# Start php-fpm server
CMD ["apache2-foreground"]

Thanks for sticking with me until the end! 😊

I know it was a lengthy read, but I hope you found it valuable and worth your time. If you have any suggestions, ideas, or thoughts to add, feel free to drop them in the comments. 👇📩

Your feedback means a lot! Don’t forget to hit that like❤️ button to show your support and stay tuned for more content. 🔔

⭐Thanks again!

#getintokube #getintokubeblogs

We will cover why Java is a hybrid of both compiled and interpreted language in a bit.

⭐Java is platform-independent but not JVM is...

Because “write once, run anywhere” concept only works on bytecode which is produced by Java compiler. However, platforms like Windows, macOS, Linus have its own version of JVM. So, Java maintains platform independence through its bytecode only.

How does Java work?

1. Writing the Java Code:

• The developer writes source code in Java typically using a .java file.

• It is a human-readable code that follows the syntax of the programming language for Java.

2. Compile to Bytecode:

• Following the writing of code, it must be compiled. There is a tool called the Java Compiler (javac) that accepts the human readable .java file and changes it into bytecode.

• Bytecode is a low-level, platform-independent representation of code that's stored in .class files

3. Execution - Java Virtual Machine (JVM):

• The compiled bytecode doesn’t run directly on the hardware like fully compiled languages (C, C++).

• Instead, it interprets the bytecode into machine code and executes the application.

⭐That’s why JAVA is called as the hybrid of Compiled and Interpreted language.

JDK vs JRE vs JVM

JDK:

• It is a whole software development kit used to write, compile, and debug Java applications.

• Includes JRE (Java Runtime Environment) + development tools (like compilers and debuggers).

JRE:

• The JRE provides everything needed to run the Java application like libraries and other dependencies, but not to develop them.

• Contains JVM (Java Virtual Machine) + core libraries and other components to run Java applications.

JVM:

• This is the engine that runs our Java applications.

• Takes the bytecode and translates it into machine code for execution.

So, to develop an application JDK is a must-have component. If we need to run a Java application, then we can use JRE alone.

Why do we need a application.properties file?

• Application configurations are usually done through an application.properties or an application.yml files.

• Especially for applications coded with frameworks such as Spring Boot, the configuration settings of such applications like ports, and database connection strings are stored using this.

Example:

# application.properties
server.port=8081

# Database settings
spring.datasource.url=jdbc:mysql://localhost:3306/mydb
spring.datasource.username=root
spring.datasource.password=pass12

Use of Java Build Tools?

• Java build tools are important in managing the complexities of building, packaging, testing, and deploying a Java application.

• Build tools such as Maven, Gradle, and Ant automatically make these processes consistent and efficient throughout the entire lifecycle of software development.

What is pom.xml & build.gradle files?

These pom.xml (used with Maven) and build.gradle (used with Gradle) are configuration files essential for managing dependencies, building, and packaging our code.

What’s in pom.xml (for Maven)?

The Project Object Model (POM) file is an XML file that defines the configuration of a Maven project.

Key Sections of pom.xml:

1. Project Information:

   • Here it defines the project's metadata like name, version, description, etc.

    <project>
      <modelVersion>4.0.0</modelVersion>
      <groupId>com.example</groupId>
      <artifactId>myapp</artifactId>
      <version>1.0-SNAPSHOT</version>
      <packaging>jar</packaging>
    </project>

2. Dependencies:

   • Dependencies are used to list external libraries (dependencies) that our project needs. Maven will automatically download these libraries from the Maven Central Repository or another repository.

    <dependencies>
      <dependency>
        <groupId>junit</groupId>
        <artifactId>junit</artifactId>
        <version>4.12</version>
        <scope>test</scope>
      </dependency>
    </dependencies>

3. Build Configuration:

   • Here we need to mention the details how to build the project, including plugins for compiling, testing, packaging, etc.

    <build>
      <plugins>
        <plugin>
          <groupId>org.apache.maven.plugins</groupId>
          <artifactId>maven-compiler-plugin</artifactId>
          <version>3.8.1</version>
          <configuration>
            <source>1.8</source>
            <target>1.8</target>
          </configuration>
        </plugin>
      </plugins>
    </build>

4. Repositories:

   • It specifies where Maven should look for dependencies if they are not found in the Maven Central Repository.

    <repositories>
      <repository>
        <id>my-repo</id>
        <url>https://my.repo.url</url>
      </repository>
    </repositories>

5. Profiles:

   • Profiles are used to configure builds for different environments, like production or development.

    <profiles>
      <profile>
        <id>prod</id>
        <build>
          <!-- Prod specific config -->
        </build>
      </profile>
    </profiles>

What’s in build.gradle (for Gradle)?

Gradle uses a DSL (Domain Specific Language), and build.gradle files can be written in Groovy or Kotlin. They are generally more concise and flexible than pom.xml.

Key Sections of build.gradle:

1. Plugins:

   • It defines the plugins that extend Gradle's functionality. For example, the java plugin helps in building Java projects.

    plugins {
      id 'java'
    }

2. Dependencies:

   • Similar to Maven, this section manages the external libraries of our project needs. Gradle can fetch these libraries from repositories like Maven Central.

    dependencies {
      implementation 'org.springframework.boot:spring-boot-starter-actuator'
      testImplementation 'org.testcontainers:junit-jupiter'
    }

3. Repositories:

   • Here it specifies where Gradle should look for dependencies. By default, Gradle uses Maven Central.

    repositories {
      mavenCentral()
    }

4. Build Script:

   • In this, we need to mention how our project should be built. We can add tasks for compilation, packaging, running tests, etc.

    tasks.register('hello') {
      doLast {
        println 'Hello, World!'
      }
    }

5. Custom Tasks:

   • Here we have a custom feature that allows us to define custom tasks to automate specific actions, giving it more flexibility than Maven in certain aspects.

    task customTask {
      doLast {
        println 'Running custom task!'
      }
    }

6. Project Information:

   • We can specify project details like group, version, etc., similar to pom.xml.

    group = 'com.example'
    version = '1.0-SNAPSHOT'

7. Build Configuration:

   • We can configure how to compile and package the project, including specifying Java versions, adding plugins, and more.

    compileJava {
      sourceCompatibility = '1.8'
      targetCompatibility = '1.8'
    }

Logging:

• Java applications typically use logging frameworks like Log4j, SLF4J, or Logback.

• Why because Logging Frameworks provide more flexible configurations comparing build-in logging and frameworks give more advantages in logging format, optimized for performance and fine-grained control over log levels.

Difference between War and Jar files:

JAR (Java Archive):

• JAR files are primarily used to package Java applications, libraries, or resources.

• Contains only compiled .class files and resources.

• Typically deploy or execute directly with the java -jar command.

• Example: A desktop application, API application or a library like spring-core.jar.

WAR (Web Application Archive):

• WAR files are specifically used to package Java web applications.

• Contains everything needed for a web application, including .class files, JSP pages, HTML, CSS, JS, and configuration files like web.xml.

• Deploy myapp.war to Tomcat by copying it to /path/to/tomcat/webapps/

• Example: A web-based application or service like myapp.war running on a Tomcat server.

Version Manager of Java:

• A version manager is a tool that allows us to easily install, manage, and switch between different versions of programming languages, frameworks, or tools.

• SDKMAN: Tools that help manage multiple versions of Java, SDK and frameworks on our system.

SDKMAN supported platforms: Linux, macOS, WSL (Windows subsystem for Linux).

Example:

• Install a specific version:

    sdk install java 11.0.11-open
  

• Switch to a different version:

    sdk use java 8.0.292-open
  

• List all available SDKs and their versions:

•           sdk list
  

Containerizing the Java application:

JAR (Java Archive):

1. Why JDK image because it includes all the tools required for compiling and packaging Java applications.

2. Copies all the files into the container directory.

3. Then clean and build the Java application based on the pom.xml

4. Use the JRE image for the runtime stage, because we already built the JAR file also it can run the application without JDK.

5. Set the working directory in the container to /app

6. Now copy the built JAR file from the build stage

7. This line indicates that the application will listen on port 8080. This does not publish the port.

8. It executes the Java application using the java.jar file

Dockerfile:

FROM techiescamp/jdk-17:1.0.0 AS build

# Copy the Java Application source code
COPY . /usr/src/

# Build Java Application
RUN mvn -f /usr/src/pom.xml clean install -DskipTests

FROM techiescamp/jre-17:1.0.0
WORKDIR /app

# Copy the JAR file from the build stage (/app)
COPY --from=build /usr/src/target/*.jar ./java.jar

# Expose the port the app runs on
EXPOSE 8080

# Run the jar file
CMD ["java", "-jar", "java.jar"]

WAR (Web Application Archive):

1. Why Tomcat image because it contains a pre-configured Tomcat server, which is used to run Java web applications.

2. Remove any default web applications that come pre-installed with the Tomcat image.

3. Now copy all the files into the container directory.

4. This line indicates that the application will listen on port 8080. This does not publish the port.

5. No CMD is needed since the base image already has a CMD instruction

# Use Tomcat base image
FROM tomcat:9.0

# Remove the default web apps
RUN rm -rf /usr/local/tomcat/webapps/*

# Copy the WAR file into the Tomcat webapps directory
COPY target/myapp.war /usr/local/tomcat/webapps/

# Expose the port on which Tomcat listens
EXPOSE 8080

# No CMD is needed since the base image already has a CMD instruction

Thanks for sticking with me until the end! 😊

I know it was a lengthy read, but I hope you found it valuable and worth your time. If you have any suggestions, ideas, or thoughts to add, feel free to drop them in the comments. 👇📩

Your feedback means a lot! Don’t forget to hit that like❤️ button to show your support, and stay tuned for more content. 🔔

⭐Thanks again!

#getintokube #getintokubeblogs