DEV Community: Pavithra Sandamini

Exploring Different Ways to Authenticate Terraform CLI with AWS

Pavithra Sandamini — Sun, 17 Nov 2024 12:04:11 +0000

Authentication is a cornerstone of securely managing infrastructure in the cloud. When using Terraform to provision resources in AWS, it’s essential to configure your CLI for seamless and secure interaction with AWS APIs. AWS offers multiple ways to authenticate your Terraform CLI. In this blog, we'll explore these methods and help you choose the best approach for your use case.

1. Using Environment Variables
The most straightforward way to authenticate Terraform with AWS is by setting environment variables. Terraform reads the following environment variables to authenticate with AWS:

AWS_ACCESS_KEY_ID: Your AWS access key ID.
AWS_SECRET_ACCESS_KEY: Your AWS secret access key.
AWS_SESSION_TOKEN (optional): Token for temporary credentials when assuming a role. Example:

export AWS_ACCESS_KEY_ID="your-access-key-id" export AWS_SECRET_ACCESS_KEY="your-secret-access-key" export AWS_SESSION_TOKEN="your-session-token" # If using temporary credentials

Environment variables are widely used in CI/CD pipelines and local development for their simplicity, but managing credentials securely can be challenging.

2. Using AWS Named Profiles
AWS CLI allows you to manage multiple sets of credentials using named profiles in the ~/.aws/credentials file. Terraform can leverage these profiles using the AWS_PROFILE environment variable or by specifying the profile in the provider block.

Example:
Setting the Profile:

export AWS_PROFILE="my-profile"

Using in Terraform:

provider "aws" { region = "us-west-2" profile = "my-profile" }
This approach is ideal for developers who manage multiple AWS accounts.

3. Using AWS IAM Roles
When running Terraform on an EC2 instance, ECS, or other AWS services, you can attach an IAM role to the instance. Terraform can automatically assume the role and fetch temporary credentials, eliminating the need to manage static keys.

How It Works:
Attach an IAM role with the necessary permissions to the instance.
Ensure Terraform is running on the instance.
No additional configuration is required; Terraform will use the instance profile.
This method is highly secure and recommended for production workloads.

4. Using the assume_role Block
If you need to assume a role in another AWS account, you can use the assume_role block within the Terraform provider configuration.

Example:

provider "aws" { region = "us-west-2" assume_role { role_arn = "arn:aws:iam::123456789012:role/MyRole" session_name = "terraform-session" } }
This approach is useful for cross-account deployments or scenarios requiring elevated permissions.

5. Using AWS SSO
AWS Single Sign-On (SSO) is a modern authentication method that allows users to authenticate without directly managing IAM keys. To use AWS SSO with Terraform:

Configure SSO using the AWS CLI:

aws configure sso

Export the SSO profile:

export AWS_PROFILE="sso-profile"

Use Terraform with the SSO profile.

AWS SSO ensures that credentials are short-lived and minimizes the risk of unauthorized access.

6. Using Credentials Helper Plugins
Terraform supports external credentials helper plugins for advanced use cases. For instance, if your organization uses tools like HashiCorp Vault, you can configure Terraform to fetch AWS credentials dynamically.

Example:
Configure the plugin in your Terraform provider block:

provider "aws" { region = "us-west-2" credentials = { plugin = "custom-plugin" } }

This method is powerful for organizations with complex security policies.

7. Using AWS CloudShell
AWS CloudShell provides a pre-configured environment with AWS CLI credentials already authenticated. Running Terraform from AWS CloudShell eliminates the need for additional authentication configurations.

How to Use:

Open AWS CloudShell in your AWS Management Console.
Install Terraform (if not already installed).
Run Terraform commands using the pre-configured AWS credentials. This approach is convenient for quick, ad-hoc tasks.

Best Practices

Use Short-Lived Credentials: Prefer temporary credentials (e.g., IAM roles, SSO) over static keys.
Secure Static Keys: If you must use static keys, rotate them regularly and store them securely (e.g., in AWS Secrets Manager).
Leverage Automation: Use CI/CD tools or automation platforms to manage credentials securely.
Monitor and Audit: Enable CloudTrail and AWS Config to monitor API activity and resource configurations.

Conclusion

Each AWS authentication method has its strengths and is suited for different scenarios. For local development, environment variables or named profiles are simple and effective. For production, using IAM roles or AWS SSO is more secure. By understanding these options, you can choose the most secure and convenient way to authenticate your Terraform CLI for AWS.

Happy Terraforming! 🎉

JavaScript Code Ethics: Writing Clean, Ethical Code

Pavithra Sandamini — Fri, 25 Oct 2024 09:46:01 +0000

In today's fast-paced development world, delivering solutions quickly is essential. However, cutting corners on code quality often leads to bugs, security vulnerabilities, and unmaintainable code. Code ethics play a pivotal role in producing not only functional but also maintainable, efficient, and secure code. Let’s explore key ethical principles in JavaScript development and how they can improve your code quality with examples.

Clarity Over Cleverness Ethical principle: Prioritize code readability and simplicity over "clever" or complex solutions. Code is read more often than written. Making it easy to understand is crucial for long-term maintenance.

Example: Avoid using terse or complex constructs when clearer alternatives exist.

Bad Example

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/zkyc8dla0ty0kgpn5vcu.png)

Good Example
const doubleArray = arr => arr.map(x => x * 2); // Clear and easily understood
In this example, the bitwise operator << works but is less readable than using simple multiplication. Choosing clarity ensures your team or future self can easily understand and maintain the code.

Avoid Global Scope Pollution Ethical principle: Avoid polluting the global scope by declaring variables globally, which can lead to name collisions and unexpected behavior.

Bad Example

let count = 0; // Declared in global scope function increment() { count++; }
Good Example

(() => { let count = 0; // Encapsulated in a closure function increment() { count++; } })();
By wrapping the code in an IIFE (Immediately Invoked Function Expression), the count variable is scoped locally, avoiding potential conflicts with other parts of the code.

Error Handling with Care Ethical principle: Handle errors gracefully and provide informative messages. Silent failures can lead to unpredictable behaviors.

Bad Example

function getUser(id) { return fetch(/user/${id}).then(res => res.json()); // No error handling }
Good Example

async function getUser(id) { try { const res = await fetch(/user/${id}); if (!res.ok) { throw new Error(Failed to fetch user: ${res.statusText}); } return await res.json(); } catch (error) { console.error('Error fetching user:', error); return null; } }
By adding error handling, you not only prevent your app from failing silently but also provide meaningful information about what went wrong.

Modularize Your Code Ethical principle: Break down large functions or files into smaller, reusable modules. This improves code organization, testing, and readability.

Bad Example

function processOrder(order) { // Code for validating order // Code for calculating total // Code for processing payment // Code for generating receipt }
Good Example

`function validateOrder(order) { /* ... / }
function calculateTotal(order) { / ... / }
function processPayment(paymentInfo) { / ... / }
function generateReceipt(order) { / ... */ }

function processOrder(order) {
if (!validateOrder(order)) return;
const total = calculateTotal(order);
processPayment(order.paymentInfo);
generateReceipt(order);
}`
This modular approach makes your code easier to understand, test, and maintain. Each function has a single responsibility, adhering to the Single Responsibility Principle (SRP).

Respect Data Privacy Ethical principle: Handle sensitive data with care. Do not expose unnecessary data in logs, console messages, or public endpoints.

Bad Example

function processUser(user) { console.log(Processing user: ${JSON.stringify(user)}); // Exposing sensitive data // ... }
Good Example

function processUser(user) { console.log(Processing user: ${user.id}); // Logging only the necessary details // ... }
In this case, the bad example exposes potentially sensitive user information in the console. The good example logs only what’s necessary, following data privacy best practices.

Follow DRY (Don't Repeat Yourself) Principle Ethical principle: Avoid code duplication. Instead, abstract repeated logic into reusable functions.

Bad Example

`function createAdmin(name, role) {
return { name, role, permissions: ['create', 'read', 'update', 'delete'] };
}

function createEditor(name, role) {
return { name, role, permissions: ['create', 'read'] };
}`
Good Example

`function createUser(name, role, permissions) {
return { name, role, permissions };
}

const admin = createUser('Alice', 'Admin', ['create', 'read', 'update', 'delete']);
const editor = createUser('Bob', 'Editor', ['create', 'read']);`
By following the DRY principle, you eliminate code duplication, reducing the chance for inconsistencies or errors in future updates.

Document Your Code Ethical principle: Document your code to ensure that your intentions and thought processes are clear for other developers (or your future self).

Bad Example

function calculateAPR(amount, rate) { return amount * rate / 100 / 12; // No explanation of what the formula represents }
Good Example

`/**

Calculate the monthly APR
@param {number} amount - The principal amount
@param {number} rate - The annual percentage rate
@return {number} - The monthly APR */ function calculateAPR(amount, rate) { return amount * rate / 100 / 12; // APR formula explained in documentation }` Good documentation ensures that anyone reading the code can understand what it does without having to reverse-engineer the logic.

Write Unit Tests Ethical principle: Writing unit tests ensures that your code works as expected and helps prevent bugs from being introduced as the code evolves.

Bad Example
// No test coverage
Good Example
// Using a testing framework like Jest or Mocha
test('calculateAPR should return correct APR', () => { expect(calculateAPR(1000, 12)).toBe(10); });
By writing tests, you ensure your code is reliable, verifiable, and easy to refactor with confidence.

Adopt a Code Style Guide Ethical principle: Follow a consistent coding style across your team or project. This improves collaboration and reduces misunderstandings.

Consider using tools like ESLint or Prettier to enforce consistency in your code.

Example ESLint Configuration

{ "extends": "eslint:recommended", "env": { "browser": true, "es6": true }, "rules": { "indent": ["error", 2], "quotes": ["error", "single"], "semi": ["error", "always"] } }
By adhering to a style guide, your codebase will maintain a consistent structure, making it easier for others to contribute and review code.

Conclusion
Ethical JavaScript coding practices ensure that your code is not only functional but also maintainable, secure, and future-proof. By focusing on clarity, modularity, error handling, and data privacy, you create a codebase that respects both your fellow developers and end users. Incorporating these practices into your workflow will help you write cleaner, more reliable code and foster a healthier development environment.

Embracing Micro Frontends: Simplifying Large-Scale Projects

Pavithra Sandamini — Fri, 11 Oct 2024 10:26:14 +0000

In the ever-evolving world of web development, managing large-scale applications can often feel like trying to juggle flaming torches. As teams grow and projects become more complex, maintaining code quality, scalability, and collaboration becomes a daunting task. Enter micro frontends—a revolutionary architectural approach that can make handling large projects not just easier but also more efficient.

What Are Micro Frontends?
Micro frontends extend the concept of microservices to the frontend world. Instead of building a monolithic frontend application, you break it down into smaller, independent units, each responsible for a specific feature or section of the user interface. These units can be developed, tested, and deployed independently, allowing teams to work in parallel and reduce bottlenecks.

Why Micro Frontends?

Scalability
One of the main challenges with large-scale projects is managing growth. As the application expands, adding new features can lead to a tangled web of code that’s hard to navigate. Micro frontends allow you to scale by splitting the application into smaller, manageable pieces. Each team can own a specific micro frontend, making it easier to scale both the code and the team.
Team Autonomy
With micro frontends, different teams can work independently on various parts of the application. This autonomy fosters a culture of ownership, as teams can make decisions about their technology stack, development practices, and deployment schedules without being held back by other teams. This can lead to faster development cycles and more innovative solutions.
Technology Agnosticism
Different teams may have different preferences when it comes to frameworks and libraries. Micro frontends allow teams to choose the technology that best fits their needs without enforcing a single tech stack across the entire application. This flexibility can lead to better performance and more tailored user experiences.
Simplified Codebase Management
A monolithic frontend can become unwieldy as it grows. Micro frontends break the codebase into smaller, more manageable parts. Each micro frontend can be developed, tested, and deployed independently, which simplifies version control and reduces the complexity of code management.
Improved Collaboration
When multiple teams work on a single codebase, conflicts can arise, leading to slower development and deployment times. Micro frontends reduce these conflicts by allowing teams to focus on their specific areas. Clear ownership and boundaries help improve collaboration and reduce friction between teams.
Easier Testing and Deployment
Testing large applications can be cumbersome. With micro frontends, you can test each unit independently, making it easier to identify issues before they escalate. Moreover, deploying micro frontends can be done in isolation, allowing for smoother rollouts and reducing the risk of breaking the entire application.
Faster Time to Market
The combination of team autonomy, simplified code management, and independent deployments translates into faster delivery of new features. Teams can push updates more frequently, allowing organizations to respond quickly to market demands and user feedback.

Implementing Micro Frontends
While the benefits of micro frontends are compelling, implementing this architecture requires careful planning and consideration. Here are some tips to get started:

Define Clear Boundaries: Establish clear boundaries between micro frontends to avoid overlap and confusion.

Choose the Right Frameworks: Consider using frameworks designed for micro frontends, such as Single SPA or Module Federation, to streamline the integration process.

Establish a Design System: A consistent design system ensures that micro frontends maintain a cohesive look and feel.

Invest in CI/CD: Continuous integration and continuous deployment pipelines are crucial for managing independent deployments effectively.

Monitor Performance: Keep an eye on the performance of individual micro frontends to ensure that they contribute positively to the overall application.

Conclusion
Micro frontends offer a powerful solution for managing the complexities of large-scale web applications. By breaking down the frontend into smaller, manageable pieces, teams can improve collaboration, enhance scalability, and deliver features faster. As with any architectural change, it requires careful planning and execution, but the potential benefits are well worth the effort.

As you consider adopting micro frontends in your projects, remember that the ultimate goal is to enhance your team’s productivity and deliver a superior user experience. In today’s fast-paced digital landscape, that’s a recipe for success.

Traffic Management with AWS Load Balancers

Pavithra Sandamini — Wed, 09 Oct 2024 11:12:07 +0000

Here are the steps to manage traffic effectively using an AWS Elastic Load Balancer:

1. Choose the Right Load Balancer
The first step in managing traffic is selecting the right type of load balancer:
Use an Application Load Balancer (ALB) if you need:
Path-based or host-based routing (e.g., example.com/app1 routes to one set of targets, example.com/app2 to another).
WebSocket support or HTTP/2 traffic.
Load balancing for containerized or microservice architectures (like ECS or EKS).

Use a Network Load Balancer (NLB) if:
You require low-latency TCP or UDP connections.
You need to handle a very large volume of traffic.

Use a Gateway Load Balancer (GWLB) for:
Directing traffic through third-party network appliances, such as firewalls, IDS/IPS systems.

2. Configure Target Groups
A target group defines how the load balancer routes requests to backend instances. For example, in an Application Load Balancer:
Targets: These can be EC2 instances, IP addresses, or Lambda functions.
Routing rules: Define how incoming traffic is distributed. You can route traffic based on:
Paths: e.g., /api/* routes traffic to your API services.
Hosts: e.g., app.example.com routes to one microservice, and admin.example.com routes to another.

For an NLB, target groups usually consist of IP addresses or EC2 instances that handle TCP/UDP traffic.
resource
`"aws_lb_target_group" "app" {
name = "app-target-group"
port = 80
protocol = "HTTP"
vpc_id = var.vpc_id

health_check {
path = "/health"
interval = 30
timeout = 5
healthy_threshold = 3
unhealthy_threshold = 2
}
}`

3. Create Listeners for Routing
Listeners are processes that check for incoming connection requests and route traffic to appropriate targets based on defined rules. For ALBs, listeners are typically configured for HTTP/HTTPS (ports 80 and 443), while NLB listeners might be for TCP/UDP traffic.
You can set up path-based or host-based routing by specifying listener rules in the Application Load Balancer. For example, for path-based routing:
resource
`"aws_lb_listener" "app_listener" {
load_balancer_arn = aws_lb.app_lb.arn
port = 80
protocol = "HTTP"
default_action {
type = "forward"
target_group_arn = aws_lb_target_group.app.arn
}
}

resource "aws_lb_listener_rule" "path_based_routing" {
listener_arn = aws_lb_listener.app_listener.arn
priority = 100
action {
type = "forward"
target_group_arn = aws_lb_target_group.api.arn
}
condition {
field = "path-pattern"
values = ["/api/"]
}
}`
Here, /api/ requests are routed to the API target group.

4. Configure Health Checks
Health checks monitor the status of your targets. If a target becomes unhealthy, the load balancer will stop sending traffic to it until it recovers.
For an Application Load Balancer:
health_check { path = "/status" interval = 30 timeout = 5 healthy_threshold = 3 unhealthy_threshold = 2 matcher = "200-299" }
The load balancer continuously checks the health of targets by sending requests to the specified path (e.g., /status) and only routes traffic to healthy targets.

5. Enable Cross-Zone Load Balancing
Cross-Zone Load Balancing ensures that traffic is distributed evenly across targets in different Availability Zones, increasing fault tolerance.
In Terraform, you can enable cross-zone load balancing like this:
resource
"aws_lb" "app_lb" { name = "app-lb" internal = false load_balancer_type = "application" enable_cross_zone_load_balancing = true security_groups = [aws_security_group.lb_sg.id] subnets = aws_subnet.subnet_ids }
This ensures that traffic is evenly distributed across all targets in all Availability Zones.

6. Auto Scaling Integration
AWS Load Balancers integrate with Auto Scaling Groups to dynamically add or remove instances based on traffic demand. The Auto Scaling Group ensures that healthy instances are automatically registered with the load balancer.
Here's an example of integrating an Application Load Balancer with an Auto Scaling Group:
resource
`"aws_autoscaling_group" "app_asg" {
desired_capacity = 2
max_size = 5
min_size = 1
vpc_zone_identifier = [aws_subnet.subnet_ids]
target_group_arns = [aws_lb_target_group.app.arn]

lifecycle {
create_before_destroy = true
}
}`
As traffic increases, the Auto Scaling Group will launch new instances and automatically register them with the load balancer, ensuring that your application can scale to handle the load.

7. SSL/TLS Termination
For secure HTTPS traffic, AWS load balancers can handle SSL termination. You can configure an SSL certificate for HTTPS traffic and offload the decryption to the load balancer, reducing the load on backend instances.
resource
`"aws_lb_listener" "https_listener" {
load_balancer_arn = aws_lb.app_lb.arn
port = 443
protocol = "HTTPS"
ssl_policy = "ELBSecurityPolicy-2016-08"
certificate_arn = aws_acm_certificate.app_cert.arn

default_action {
type = "forward"
target_group_arn = aws_lb_target_group.app.arn
}
}`

Conclusion
AWS Load Balancers provide powerful features for managing traffic across multiple instances or services, ensuring high availability, scalability, and security. Whether you need advanced routing with an Application Load Balancer or ultra-low latency with a Network Load Balancer, AWS provides the tools you need to manage traffic effectively.
By integrating features like Auto Scaling, SSL termination, health checks, and cross-zone load balancing, you can optimize your application's performance, reliability, and security.
With this understanding, you can confidently manage traffic for a range of scenarios using AWS Elastic Load Balancers!

Setup role based access with AWS IAM

Pavithra Sandamini — Sat, 14 Sep 2024 15:08:03 +0000

Step 1: Understanding AWS IAM
AWS IAM enables you to securely manage access to AWS services and resources. With RBAC, you can assign specific roles to users based on their access needs, and grant permissions through policies. This allows your application to control what actions users can perform within your web app, depending on their roles.

Step 2: Set Up IAM Roles and Policies

Create IAM Policies IAM policies define what actions (like read, write, etc.) a user is allowed or denied. These policies are JSON documents attached to roles or users.

Example JSON Policy:
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:ListBucket", "s3:GetObject" ], "Resource": [ "arn:aws:s3:::your-bucket-name", "arn:aws:s3:::your-bucket-name/*" ] } ] }

This policy allows a user with this role to read objects from an S3 bucket.

Create IAM Roles Roles are groups of permissions that can be assigned to IAM users or services.

Admin Role: Full access to all resources.
Read-Only Role: Permission to view certain resources.
Manager Role: Permissions to modify specific resources.

aws iam create-role --role-name AdminRole --assume-role-policy-document file://trust-policy.json aws iam create-role --role-name ReadOnlyRole --assume-role-policy-document file://trust-policy.json

The trust policy defines which entities can assume the role.

Assign Roles to Users You can attach these roles directly to specific IAM users or through groups. When users log in, their access is determined by the role they have.

aws iam add-user-to-group --user-name john_doe --group-name AdminGroup

Step 3: Configure Web Application for Role-Based Access
Now that your roles and policies are set up, you can implement role-based access in your web application using AWS SDK for programmatic access to IAM.

Backend: Setting Up AWS SDK
Install AWS SDK in your application backend:

npm install aws-sdk

Configure AWS credentials and permissions in your web app:

`const AWS = require('aws-sdk');
AWS.config.update({
accessKeyId: process.env.AWS_ACCESS_KEY_ID,
secretAccessKey: process.env.AWS_SECRET_ACCESS_KEY,
region: 'us-west-2'
});

const sts = new AWS.STS();

function assumeRole(roleArn) {
return sts.assumeRole({
RoleArn: roleArn,
RoleSessionName: 'webAppSession'
}).promise();
}

assumeRole('arn:aws:iam::123456789012:role/AdminRole').then(data => {
console.log('Assumed Role: ', data);
}).catch(error => {
console.error('Error assuming role: ', error);
});`

This script authenticates the user, assumes a specific role, and grants the corresponding permissions.

Backend: Authorization Middleware
Next, implement a middleware that checks user roles and grants access accordingly.

`
function checkRole(requiredRole) {
return (req, res, next) => {
const userRole = req.user.role; // This comes from your auth system

if (userRole !== requiredRole) {
  return res.status(403).json({ error: 'Access Denied: Insufficient permissions' });
}

next();

};
}

app.get('/admin', checkRole('Admin'), (req, res) => {
res.send('Welcome Admin');
});

app.get('/reports', checkRole('Manager'), (req, res) => {
res.send('Manager Reports');
});`

This middleware checks the user's role before allowing access to routes.

Step 4: Frontend Integration
For the frontend, restrict UI components based on user roles. Assuming you’re using React, this can be achieved with role-based rendering:

function AdminDashboard({ user }) {
if (user.role !== 'Admin') {
return

Access Denied

;
}

return (

Admin Dashboard

{/* Admin functionality */}

);
}

function App() {
const user = { role: 'Admin' }; // User role comes from auth

return (

);
}

Here, the AdminDashboard is only accessible if the logged-in user has the Admin role.

Step 5: Securing API Requests with Signed AWS Requests
For sensitive operations like interacting with AWS services, sign your API requests using the user's role. AWS provides signature version 4 signing for secure requests.

`const AWS = require('aws-sdk');

const s3 = new AWS.S3({
accessKeyId: process.env.AWS_ACCESS_KEY_ID,
secretAccessKey: process.env.AWS_SECRET_ACCESS_KEY
});

function listS3Buckets() {
return s3.listBuckets().promise();
}

listS3Buckets().then(buckets => {
console.log('S3 Buckets: ', buckets);
}).catch(err => {
console.error('Error listing buckets: ', err);
});`

If your application needs to allow access to external users (outside of AWS IAM), you can use AWS Cognito or other identity providers for federated access. AWS Cognito integrates with IAM roles, enabling you to assign AWS permissions to external users based on their role.

Conclusion
With AWS IAM and role-based access control, you can manage and secure your web application’s users based on their roles, ensuring that they only have access to the resources they need. By setting up IAM roles and policies, integrating AWS SDK in your backend, and enforcing role-based access in both the frontend and backend, you can create a secure and scalable web application.

Make sure to follow security best practices by using environment variables for sensitive credentials and employing least privilege principles when assigning permissions.

How to Improve Code Quality

Pavithra Sandamini — Tue, 20 Aug 2024 04:17:31 +0000

Hi developers, Are you struggling with enhancing your code performance and readability? Let me tell you a bunch of secrets. Here, we are talking about how we can enhance our code quality better. First things first, what is the quality of our code, and what are the criteria that measure it? An important component of software development is code quality, which enhances the efficiency, dependability, and maintainability of the codebase. Ok, dear devs, let's dig into all the metrics one by one.

Understand the requirement

When you have some requirement from your client, you need to understand it thoroughly and create a breakdown of the task into stories. It will help you to understand the code that you want to write and what are the learning and prerequisites you want. As an additional benefit, you will get a proper idea of how to manage your code within the given timeline. So, you will do it without any stress.

Use a version control system

In here you are not single, you will work with your fellow co-workers. That's why we need version control. Version control makes it simpler to roll back to earlier iterations of the code when needed by keeping track of changes made to it over time. Additionally, version control makes it possible for several developers to collaborate on the same codebase at once without running into problems or losing work.

The following are some advantages of version control:
Monitor code changes over time: Keeping track of code changes makes it simpler to roll back to earlier iterations when needed. This is particularly helpful if there are any bugs or other problems with the code.
Working together: Teamwork and developer efficiency are increased when numerous developers may collaborate on the same codebase at once without running afoul of one other or losing work.
Backup: Version control keeps a copy of the codebase so that errors or mishaps can be corrected.
Enhanced openness: It is simpler to comprehend who made modifications and why when there is a clear history of those changes in the code. This can enhance accountability and openness within a team.
There are a large number of version control systems out there, Git being one of the most widely used. It's critical to adhere to standard practices while utilizing version control, which include managing branches, crafting informative commit messages, and routinely merging changes into the main codebase. It also includes another thang.

Use Code Reviews

In our codes reviewing plays a significant role. Code reviews are a process when one or more developers go through the work of another dev and offer comments, ideas and recommendations for enhancements. Code reviews are much needed for any successful application development team as they aid in finding problems, enhance readability, and guarantee that the code adheres to best practices and standards.
The following are some advantages of code reviews:
Better code quality: Eliminates errors and raises the standard of the code as a whole.
Enhanced cooperation: Facilitates developer cooperation, enhancing communication and teamwork.
Enhanced exchange of knowledge: gives team members a means of exchanging best practices and expertise, which raises the code's overall quality.
Decreased chance of bugs: Early bug detection increases the code's overall reliability.
The following should always be kept in mind when performing code reviews:
Promote candid and open feedback: Code reviews ought to be a secure environment where engineers may give candid and helpful criticism to one another.
Prioritize the code over the person: Reviews of code ought to concentrate on the code itself rather than the author. Comments ought to be helpful and directed toward making the code better rather than criticizing the person.
Make it a team effort: Code reviews ought to be carried out as a team, with several developers contributing comments and cooperating to make the code better.

Automate Your Testing

Here, testing is one of the best ways to identify the mistakes that you have made. Here, testing can vary with your organization's practices. Some of them are tested by QA, and then the issues are fixed. But there is a better way to improve yourself and that is to execute unit tests using a test framework.
Here, with unit testing, you will get a chance to ensure that your implementation is working as expected and test every nook and corner of the user scenarios to identify the issues. So, testing yourself is another best way to improve your code quality.

Maintain Updated API documentation.

A well-documented API is a beacon of clarity. It will help not only you but also
every role, like devs, QA, and automation engineers, to identify the application referring to a single document.
Stay Updated on latest practices
Coding is a field that updates in real-time. It is updating the time that you read this. So, to go through it, you should update it, too. Improving and maintaining yourself with the latest code ethics will reflect your code quality.

Refactor your code regularly.

Restoring is changing the code structure without altering its functionality. Rewriting parts of the code improves readability, performance, and maintainability. And it will decrease the chances that cause errors in your code.
When you are refactoring your code, the following things should be kept in mind.
Write the automated tests: As I mentioned earlier, the test cases should be written or updated according to the refactoring that you have done.
Document changes: In the API documentations that you have created should be updated with the changes in real time. It will help everyone to understand the code well.
Make small incremental changes: When refactoring code, small changes are crucial because big changes make it harder to find flaws. It is also easy to roll back to earlier versions when needed thanks to minor adjustments.
Those are some important things that you need to pay attention to when coding quality. Hope you will get the best out from this to improve your code quality and ethics. Good luck devs and happy coding….!

Kubernetes concepts part -3 Introduction to services & Ingress

Pavithra Sandamini — Sun, 31 Dec 2023 06:16:03 +0000

Hello folks, today we are going to get a wide understanding about services in Kubernetes and also the Ingress. So, from part one and two I gave you some background knowledge about Kubernetes and their workloads. Now we can expand our knowledge with services and Ingress. So, let's go then.

Services:
A way to expose a network application that is operating as one or more Pods in your cluster is called a service in Kubernetes. The fact that using a new service discovery mechanism doesn't need changing your current application is one of the main goals of Services in Kubernetes. Code that was created for a cloud-native environment or an older app that you containerized can both be executed in Pods. To enable clients to interact with that collection of Pods, you utilize a Service to make them accessible via the network. Here I attached some sample code for your YAML file to create your first service.

And there is three main service types. Those are ClusterIP, Nodeport and loadebalancer. Now we can explore them one by one.

ClusterIP:
An IP address is assigned by this default service type from a pool of IP addresses that your cluster has set aside specifically for that use. The ClusterIP type serves as the basis for a number of other Service types. Kubernetes does not allocate an IP address to a service that you specify with the.spec.clusterIP set to "None". Refer to headless Services for additional details.
When submitting a request for the development of a service, you can include your own cluster IP address. Set the.spec.clusterIP field to accomplish this. For instance, if you want to reuse an existing DNS entry or if you have legacy systems that are hard to reconfigure and are set up for a specific IP address.
The IP address you select needs to be a working IPv4 or IPv6 address that falls under the CIDR range service-cluster-ip-range that is set up for the API server. An error 422 HTTP status code will be returned by the API server if you attempt to create a Service with an invalid clusterIP address value.

NodePort:
The Kubernetes control plane assigns a port from the range indicated by the --service-node-port-range flag (default: 30000-32767) if the type field is set to NodePort. Every node proxies that port into your service (which is the same port number on every node). The assigned port is reported by Your Service in the field called.spec.ports[*].nodePort.
You can setup environments that Kubernetes does not completely support, create your own load balancing solution, or even expose the IP addresses of one or more nodes directly by using a NodePort.
You can enter a value in the nodePort field to indicate a specific port number. Either that port will be assigned to you by the control plane, or it will report that the API transaction failed. This implies that you are responsible for handling any potential port clashes. Additionally, the port you use must be inside the range set up for NodePort use.
This is a sample manifest that defines a NodePort value (30007 in this case) for a Service of type:

Load-Balancer:
You can enter a value in the nodePort field to indicate a specific port number. Either that port will be assigned to you by the control plane, or it will report that the API transaction failed. This implies that you are responsible for handling any potential port clashes. Additionally, the port you use must be inside the range set up for NodePort use.
This is a sample manifest that defines a NodePort value (30007 in this case) for a Service of type:

The backend Pods receive traffic that is directed from the external load balancer. The load balancing mechanism is chosen by the cloud provider.
Kubernetes usually begins by making the necessary modifications to match your request for a Service of type: NodePort in order to create a Service of type: LoadBalancer. The external load balancer is then set up by the cloud-controller-manager component to send traffic to the designated node port.
When configuring a load-balanced service, you can choose not to assign a node port as long as the cloud provider implementation permits it.
You may be able to define the loadBalancerIP with certain cloud providers. In some situations, the loadBalancerIP that the user specifies is used to create the load-balancer. The load balancer is configured with an ephemeral IP address if the loadBalancerIP field is left empty. The loadbalancerIP field you set is disregarded if you supply one but your cloud provider does not support the capability.

So this is my description about Kubernetes services and then, I'm going to tell share some knowledge about ingress in Kubernates.

Ingress:
This is an API object that manages external access to the services in a cluster, typically HTTP. Ingress may provide load balancing, SSL termination and name-based virtual hosting. Services within the cluster can access HTTP and HTTPS routes from outside the cluster through ingress. Rules that are defined on the Ingress resource govern traffic routing. And here I added some sample image for your understanding.

And there is two basic routing methods called, path based routing and name based routing.

So, this is the content that I hope to cover in this article and hope you guys got some background idea about Kubernetes services & ingress. stay tuned for next...

Deploying a Node.js Express API on Amazon ECS (Elastic Container Service)

Pavithra Sandamini — Fri, 29 Dec 2023 01:07:35 +0000

Greetings from a cloud trip, fellow devs! Installing programs that are reliable and scalable is crucial in the current fast-paced web development industry. One of the best methods to do this is to orchestrate your application on the cloud using containerization. This post will explore the fascinating world of utilizing Amazon Elastic Container Service (ECS) to install a Node.js Express API. Delivering a Node.js Express API involves building a Docker container, publishing it to a container registry, and then deploying it to Amazon ECS (Elastic Container Service). The general instructions for it are located here. But first, there are a few prerequisites that you need to fulfill. These are outlined below.

Prerequisites:
AWS CLI:
Ensure that your local machine have the AWS CLI installed because it will help to mange via command line.

Docker:
Make sure you have Docker latest version installed in your local machine to build your Docker image.

Step 1:
The very first step to create the docker file. Here I created a sample docker file that matches my Node.js Express application.
Here's the code for the my docker file.

`Copy code
FROM node:14

WORKDIR /usr/src/app

COPY package*.json ./

RUN npm install

COPY . .

EXPOSE 3000

CMD ["node", "app.js"]`

Step 2:
After creating your docker file, build it locally. I will add the command below.

docker build

This command will create a docker image for your application. And then push your docker image into AWS ECR. I added all the steps for that in below. SO, now follow it with me.

Step 3:
To push your image into ECR we will create a repository on AWS ECR. I added the code lines in creating ECR repo using CLI.

aws ecr create-repository --repository-name your-repository-name
After creating the repo, you should build and tag your docker image using the code below.

docker build -t your-repository-name:tag .
So, now you have tagged your image. After that authenticate docker into your ECR repo. For that,

aws ecr get-login-password --region your-region | docker login --username AWS --password-stdin your-account-id.dkr.ecr.your-region.amazonaws.com
Hureeeh, now you have successfully authenticated your docker image into ECR repo. Then, push the docker image into ECR repository using command below.

docker tag your-repository-name:tag your-account-id.dkr.ecr.your-region.amazonaws.com/your-repository-name:tag docker push your-account-id.dkr.ecr.your-region.amazonaws.com/your-repository-name:tag
Next, create a job definition in YAML or JSON that includes the RAM, CPU, Docker image, and any environment variables. Here, I've included a few JSON-formatted task definition files.

{ "family": "your-task-family", "containerDefinitions": [ { "name": "your-container", "image": "your-account-id.dkr.ecr.your-region.amazonaws.com/your-repository-name:tag", "portMappings": [ { "containerPort": 3000, "hostPort": 3000 } ], "essential": true } ] }

Step 4:
The ECS cluster will be created as the next step.#:~:text= Launch the ECS console%20in,template%20select%20EC2%20Networking%20%2B%20Linux%).
Next, use the task specification you created to execute your ECS task.

aws ecs run-task --cluster your-cluster-name --task-definition your-task-family

Make an Application Load Balancer (ALB) and link it to your ECS service if your API needs external access.

Use the ALB URL to test your Node.js Express API when the task has completed and the service has been connected to the ALB.

Don't forget to include your actual values in placeholders like your-repository-name, your-region, your-account-id, your-task-family, your-cluster-name, and others. Furthermore, modify parameters based on the requirements of your application.
So, now you have successfully deployed your API in ECR. I hope you all learned a lot. Stay tuned for more...

Introduction to Core Objects & workloads - Kubernetes part 2

Pavithra Sandamini — Wed, 27 Dec 2023 11:12:39 +0000

Hi folks, so I hope you guys enjoyed my first blog about Kubernetes introduction and here we go again with the core objects and workloads of Kubernetes. There are pods, namespaces, labels and selectors. Now we can observe the one by one.

Pods:
Pod is the smallest unit that can be deploy into the cluster. A Pod (as in a pod of whales or pea pod) is a group of one or more containers, with shared storage and network resources, and a specification for how to run the containers.
So, when creating a pod we can use some commonly use commands, I will add them below for your understanding.
kubectl -f <filename.yaml>
Using this command you can create a pod and the content that need to create the pod should be attach into filename file in YAML format.
After creating the pod you can list all pods using command,
po
So, those are the main concepts about the pods in brief. Then let's dive into labels.

Labels:
Key/value pairs called labels are affixed to objects, such Pods. Although labels do not immediately imply semantics to the main system, they are meant to be used to indicate distinguishing features of objects that are meaningful and important to users. Subsets of objects can be arranged and chosen using labels. At the moment of creation, labels can be affixed to objects, and they can be added or changed at any point. A set of defined key/value labels may be present in each object. Every key for a certain item needs to be distinct. Then let's move on to our next topic, that is selectors.

Selectors:
Another important component of Kubernetes is selectors. selectors is a field present in most Kubernetes objects that selects based on labels. Set-based and equity-based selectors are the two different varieties. More sophisticated operations like in, not in, or, and exists are possible with the latter. Both the equality-based match labels and the set-based match expressions must be true if they are supplied.

In services, labels and selectors are important. For example, a service uses labels and selectors to choose which pods to send traffic to. The service will route traffic to the pods that fit the label app nginx if ports are labeled based on app nginx and the selector is based on {app nginx}. This is about selectors and then we will go through the workloads and their methos.

Workloads:
A Kubernetes application is called a workload. Using Kubernetes, your workload is executed inside a collection of pods, regardless of how many interdependent components it consists of. A cluster of containers that are currently executing on Kubernetes is represented by a Pod.

Pods in Kubernetes have a specified lifespan. For instance, if a catastrophic defect occurs on the node where a pod is executing in your cluster, all of the pods on that node would fail. Even if the node later recovers, Kubernetes views that degree of failure as final and requires you to construct a new Pod in order to recover.

However, you don't have to actively manage each Pod, which will greatly simplify your life. Alternatively, you can use workload resources to handle a group of pods under your control. These resources set up controllers to ensure that the desired number and kind of pods are operating in the desired state.

Numerous workload resources are integrated into Kubernetes, those are replicaset, deployment, demonset, statefulset, job and cronjobs. Now I'll go through one by one.

Replicaset: - This is the primary method of managing pod replicas & their lifecycle. And always this will ensure the desired number of pods are running. This yaml file that added below will help you to get some idea about the yaml file format when creating a replicaset.

Deployment: - This is the way of managing pods via replicaset, because we cannot create a replicaset directly. We will create a replicaset using deployment. And also this will provide rollback functionality and update control. This updates are managed through the pod-template-hash label. This is an example yaml file for an deployment.

Demonset: - This demonset will ensure that all nodes matching certain criteria will run an instance of the supplied pod.And also this demonsets are ideal for cluster wide services such as log forwarding or monitoring.

Statefulset - Statefulset is tailored to managing pods that must persist or maintain state. It will assign an unique ordinal name following the convention of ,

And also it will be useful when stable, unique network identifiers, stable, persistent storage and ordered, graceful deployment and scaling.

Job - All workloads that we learn before are used to continuous running clusters. But if we need some workload to run until their task is completed, we use jobs. In jobs it always running for a specific task and after it is completed, the job will terminated.

CronJobs - Cronjobs are an extension of the job controller, it provides a method of executing jobs on a cron-like schedule.

Schedule - the cron schedule for the job.
SuccessfulJobHistoryLimit - the number of successful jobs to retain.
FailedJobHistoryLimit - the number of failed jobs to retain.

References:

Introduction to Kubernetes

Pavithra Sandamini — Wed, 27 Dec 2023 03:33:25 +0000

Hi everyone, today I will be expanding your understanding of Kubernetes and its fundamental principles. The goal of the open-source container orchestration platform Kubernetes is to automate the deployment, scaling, and administration of applications that are containerized. Kubernetes, which was initially created by Google and is currently managed by the Cloud Native Computing Foundation (CNCF), offers a stable and adaptable framework for managing the lifecycle of applications that operate in containers.
At this point, we can discuss the reasons behind and advantages of Kubernetes use.

Because Kubernetes solves a number of issues related to deploying, scaling, and managing containerized applications in complex settings, people and organizations utilize it for a variety of purposes. Container orchestration, scalability, high availability, declarative configuration, portability, and cost effectiveness are some of the main uses for Kubernetes.

If I were to elaborate on container orchestration, I would say that it is an essential component of deploying modern applications, particularly when considering microservices design. It entails automating containerized application deployment, scalability, and management. Although managing large-scale container deployments manually can be challenging, containers offer consistency across many environments by encapsulating an application and its dependencies. These issues are addressed by container orchestration systems such as Docker Swarm, Apache Mesos, and Kubernetes. However, docker swarm is primarily used for container orchestration.

Ok folks, let's go through the key concepts of Kubernetes. They are node, cluster, master & worker, pod, container, service and namespace. So, now I will walk you through one by one.

Node: In Kubernetes, a Node is a worker machine that can be virtual or physical, depending on the cluster. All Nodes are under the control plane's management. Numerous pods can exist on a single Node, and the Kubernetes control plane manages the scheduling of the pods among the cluster's Nodes automatically.

Cluster: A collection of machines running containerized apps is called a Kubernetes cluster. Applications that are containerized come packaged with some required services and dependencies. Compared to virtual machines, they are more versatile and lightweight. Kubernetes clusters make it easier to develop, migrate, and manage apps in this way.

Containers may operate on-premises, in the cloud, on virtual computers, and in physical environments thanks to Kubernetes clusters. Unlike virtual machines, Kubernetes containers are not limited to a particular operating system. Rather, they can run anywhere and share operating systems.
One master node and several worker nodes make up a Kubernetes cluster. Depending on the cluster, these nodes may be virtual or actual computers.

Worker and master: One master node and multiple worker nodes make up a Kubernetes cluster. The worker nodes are in charge of managing the containers and completing any tasks that the master node assigns them. The master node manages cluster state maintenance, application scheduling and scalability, and update implementation.

Pod:

The smallest deployable compute units that Kubernetes allows you to construct and control are called pods. A group of one or more containers with shared network and storage resources and operating instructions is referred to as a pod (as in, say, a pod of whales or a pod of peas).

Container: Kubernetes containers resemble virtual machines (VMs), each with its own CPU share, filesystem, process space, memory, and more. However, Kubernetes containers are considered lightweight because: they can share the Operating System (OS) among applications due to their relaxed isolation properties.

Service: A collection of pods is connected to an IP address and abstracted service name via Kubernetes services. Services facilitate pod-to-pod discovery and routing. Services, for instance, link the front end and back end of an application, which are both operating on different cluster deployments.

Namespace:

An organization can utilize Kubernetes namespaces to separate and classify a single cluster into several sub-clusters that can be independently managed. These clusters can each operate as separate modules where users from different modules can communicate and exchange data as needed.

So, I hope you guys got a wide understanding about Kubernetes and their core concepts. So let's deep dive into those in my next blog. Stay tuned........

Resources: