DEV Community: xinacod

Auto Deploying Apps Using AWS + Kustomize

xinacod — Wed, 14 Feb 2024 12:41:19 +0000

Kustomize is a tool for customizing Kubernetes configurations, simplifying the rollout and deployment of applications into clusters. It has the following features to manage application configuration files:

generating resources from other sources
setting cross-cutting fields for resources
composing and customizing collections of resources_ In this scenario, you'll learn how to use Kustomize Bases and Overlays to deploy 3 different versions (Baseline, Staging, and Production) of the same sample web application into a provided Kubernetes cluster.

Blog Objectives:
Upon completion of this article, you should be able to:

Use Kustomize to deploy a basic web application which has been packaged already into a docker image (hosted on DockerHub).
Understand how to use configure and work with Kustomize Bases and Overlays
Use Kustomize to generate 3 different enviroment specific deployments:

Baseline - the baseline deployment version of the webapp
Staging - uses a Kustomize overlay to change the baseline deployment settings
Production - uses a Kustomize overlay to change the baseline deployment settings Test and validate the Base, Staging, and Production deployed cluster resources using the curl command and your workstations browser

You should:

Be comfortable with basic Linux command line administration
Be comfortable with basic Kubernetes and Container based concepts

The AWS Management Console is a web control panel for managing all your AWS resources, from EC2 instances to SNS topics. The console enables cloud management for all aspects of the AWS account, including managing security credentials and even setting up new IAM Users.

Instructions

In the AWS Management Console search bar, enter EC2, and click the EC2 result under Services:

Click on Instances. Wait for the ide.cloudacademy.platform.instance EC2 instance to be launched, and then select it, and locate and copy the assigned IPv4 Public IP address. An example IPv4 address number is 54.69.21.244
The web-based CloudAcademy IDE has been configured on port 80. Using your browser, navigate to the IDE hosted on the ide.cloudacademy.platform.instance EC2 instance using the public IP address you just copied:

Note:

Remember to use the public IP address assigned to your ide.cloudacademy.platform.instance.
It takes approximately 1-2 minutes for the web-based CloudAcademy IDE service to startup on the ide.cloudacademy.platform.instance EC2 instance - try refreshing the browser page request until access is successful - please be patient.
It has been configured to listen on port 80
An example URL would be http://35.91.56.109 where "35.91.56.109" is the public IP from the last instruction

In this Lab Step, you'll use Kustomize to perform a baseline deployment of the sample web application into the provided Kubernetes cluster. Kustomize is now natively built into the standard kubectl command, which you'll use to drive the deployment. You'll then use your browser to confirm that the baseline version of the sample web application is indeed correctly deployed and configured.

Instructions
1. Expand the Files tree view by clicking on the Files tab on the left handside menu, and then open the project/code/kustomize/base directory:

The base directory contains the following 4 manifest files which are used to create a basic sample web application within the cluster. Open each of the following files within the editor view and then review their contents.

configmap.yaml
deployment.yaml
service.yaml
ingress.yaml

The base directory also contains a kustomization.yaml file, which consists of the following configuration:

*Copy code
*



commonLabels:

 app: webapp

 env: base

 version: "1.02"

 org: cloudacademy.com

 team: devops.labs

 developer: jeremy.cook



resources:

- configmap.yaml

- deployment.yaml

- service.yaml

- ingress.yaml

The commonLabels section defines common metadata labels which get copied into each of the 4 manifest files declared in the resources section when Kustomize is executed.

Start a new terminal session by right clicking on the kustomize directory within the Files tree view and then selecting the Open in Terminal option: 6. Confirm that you are in the /home/project/code/kustomize directory. In the terminal execute the following command:

**Copy code
`cd /home/project/code/kustomize && ls -la

. Use Kustomize to generate and output the set of API resources as declared within the kustomization.yaml file within the base directory. In the terminal execute the following command:

kubectl kustomize base

Now use Kustomize to deploy the same baseline set of resources into the provided Kubernetes cluster. In the terminal execute the following command:

Confirm that all cluster resources were created successfully. In the terminal execute the following command:

Kubectl get all

The sample web application should now be ready to serve Internet based traffic via its assigned FQDN host declared within the base/ingress.yaml file. Display the contents of the base/ingress.yaml file. In the terminal execute the following command:

For your convenience the same FQDN host has been stored in the WEBAPP_URL_BASE environment variable. It can be retrieved by running the following command within the terminal:

Take note of the "Base" text and yellow background colour of the rendered web page. These settings are declared within the base/configmap.yaml file, which is itself referenced by the base/deployment.yaml file:

Introduction
In this Lab Step, you'll use Kustomize to perform the staging deployment of the sample web application into the provided Kubernetes cluster. You'll then use your browser to confirm that the staging version of the sample web application is indeed correctly deployed and configured.

Instructions
1. Expand the Files tree view by clicking on the Files tab on the left handside menu, and then open the project/code/kustomize/overlays/staging directory:

The staging directory contains 2 x k8s manifest files and 1 x kustomize config file. The k8s manifest files contain updated settings which will be used to create the staging sample web application resources within the k8s cluster. Open each of the following files within the editor view and review their contents.

configmap.yaml - note the updated message and bgcolor values
ingress.yaml - note the updated host value

The staging directory contains a kustomization.yaml file with the following configuration:
Copy code
`
namePrefix: stg-

commonLabels:

env: staging

commonAnnotations:

note: staging deployment of cloudacademy lab webapp

bases:

../../base

`
patchesStrategicMerge:

configmap.yaml
ingress.yaml
`
Notes:
namePrefix defines a string that is added to the start of all resource names
commonLabels defines metadata labels that are added to all resources
commonAnnotations defines metadata annotations that are added to all resources
bases defines the base directory which is to be merge patched with the resources declared in the patchesStrategicMerge section
Start a new terminal session by right clicking on the staging directory within the Files tree view and then selecting the Open in Terminal option:
Confirm that you are in the /home/project/code/kustomize/overlays/staging directory. In the terminal execute the following command:

cd /home/project/code/kustomize/overlays/staging && ls -la

Use Kustomize to generate and output the set of API resources as declared within the kustomization.yaml file within the staging (current) directory. In the terminal execute the following command:

`
Copy code
kubectl kustomize .

. Now use Kustomize to deploy the staging generated set of resources into the Kubernetes cluster. In the terminal execute the following command:

*Copy code
*kubectl apply -k .

The staging sample web application should now be ready to serve Internet based traffic via its assigned FQDN host declared within the staging/ingress.yaml file. Display the contents of the staging/ingress.yaml file. In the terminal execute the following command:

Copy code
cat ingress.yaml

For your convenience the same FQDN host has been stored in the WEBAPP_URL_STAGING environment variable. It can be retrieved by running the following command within the terminal:

**Copy code
export | grep WEBAPP_URL_STAGING

Using your own web browser, browse to the URL stored in the WEBAPP_URL_STAGING environment variable and confirm that the staging sample web application renders successfully:

Take note of the "Staging" text and the orange background colour of the rendered web page. These settings are declared within the staging/configmap.yaml file, which is itself referenced by the base/deployment.yaml file:

Copy code
apiVersion: v1

kind: ConfigMap

metadata:

name: webapp-cfg

data:

message: "Staging"

bgcolor: "orange"

Close all currently open files within the editor.
Close the currently opened terminal session (bottom) pane - leaving the IDE open. The production directory contains 3 x k8s manifest files and 1 x kustomize config file. The k8s manifest files contain updated settings which will be used to create the production sample web application within the cluster. Open each of the following files within the editor view and review their contents.

configmap.yaml - note the updated message and bgcolor values
deployment.yaml - note the updated replicas value
ingress.yaml - note the updated host value

The production directory contains a kustomization.yaml file with the following configuration:

Copy code
namePrefix: prod-

commonLabels:

env: prod

commonAnnotations:

note: production deployment of cloudacademy lab webapp

bases:

../../base

patchesStrategicMerge:

configmap.yaml
deployment.yaml
ingress.yaml
Notes:
namePrefix defines a string that is added to the start of all resource names
commonLabels defines metadata labels that are added to all resources
commonAnnotations defines metadata annotations that are added to all resources
bases defines the base directory which is to be merge patched with the resources declared in the patchesStrategicMerge section
Start a new terminal session by right clicking on the production directory within the Files tree view and then selecting the Open in Terminal option:

5. A new terminal session is presented in the bottom pane:

6. Confirm that you are in the /home/project/code/kustomize/overlays/production directory. In the terminal execute the following command:

*Copy code
*
cd /home/project/code/kustomize/overlays/production && ls -la
7. Use Kustomize to generate and output the set of API resources as declared within the kustomization.yaml file within the production (current) directory. In the terminal execute the following command:

*Copy code
*
kubectl kustomize .

8. Now use Kustomize to deploy the production generated set of resources into the Kubernetes cluster. In the terminal execute the following command:

*Copy code
*
kubectl apply -k .

Confirm that all production cluster resources were created successfully. In the terminal execute the following command:

*Copy code
*
kubectl get all -l env=prod

The production sample web application should now be ready to serve Internet based traffic via its assigned FQDN host declared within the production/ingress.yaml file. Display the contents of the production/ingress.yaml file. In the terminal execute the following command:

*Copy code
*
cat ingress.yaml

For your convenience the same FQDN host has been stored in the WEBAPP_URL_PROD environment variable. It can be retrieved by running the following command within the terminal:

**Copy code
`export | grep WEBAPP_URL_PROD
12. Using your own web browser, browse to the URL stored in the WEBAPP_URL_PROD environment variable and confirm that the production sample web application renders successfully:

Take note of the "Production" text and the cyan background colour of the rendered web page. These settings are declared within the production/configmap.yaml file, which is itself referenced by the base/deployment.yaml file:

Copy code



apiVersion: v1

kind: ConfigMap

metadata:

  name: webapp-cfg

data:

  message: "Production"

  bgcolor: "cyan"

Recourses

https://github.com/xenacode-art/Kustomize

AWS + DevSecops

xinacod — Mon, 19 Sep 2022 12:28:25 +0000

DevSecops Defined

DevSecOps is the practice of integrating security testing at every stage of the software development process. It includes tools and processes that encourage collaboration between developers, security specialists, and operation teams to build software that is both efficient and secure. DevSecOps brings cultural transformation that makes security a shared responsibility for everyone who is building the software.

What does DevSecOps stand for?

DevSecOps stands for development, security, and operations. It is an extension of the DevOps practice. Each term defines different roles and responsibilities of software teams when they are building software applications.
Development

Development is the process of planning, coding, building, and testing the application.
Security

Security means introducing security earlier in the software development cycle. For example, programmers ensure that the code is free of security vulnerabilities, and security practitioners test the software further before the company releases it.
Operations

The operations team releases, monitors, and fixes any issues that arise from the software.

DevSecOps aims to help development teams address security issues efficiently. It is an alternative to older software security practices that could not keep up with tighter timelines and rapid software updates. To understand the importance of DevSecOps, we will briefly review the software development process.

Software development lifecycle

The software development lifecycle (SDLC) _is a structured process that guides software teams to produce high-quality applications. Software teams use the SDLC to reduce costs, minimize mistakes, and ensure the software aligns with the project's objectives at all times. The software development life cycle takes software teams through these stages:

Requirement analysis
Planning
Architectural design
Software development
Testing
Deployment

DevSecOps in the SDLC [software development life cycle]

In conventional software development methods, security testing was a separate process from the SDLC. The security team discovered security flaws only after they built the software. The DevSecOps framework improves the SDLC by detecting vulnerabilities throughout the software development and delivery process.

What are the benefits of DevSecOps?

There are several benefits of practicing DevSecOps.
Catch software vulnerabilities early

Software teams focus on security controls through the entire development process. Instead of waiting until the software is completed, they conduct checks at each stage. Software teams can detect security issues at earlier stages and reduce the cost and time of fixing vulnerabilities. As a result, users experience minimal disruption and greater security after the application is produced.
Reduce time to market

With DevSecOps, software teams can automate security tests and reduce human errors. It also prevents the security assessment from being a bottleneck in the development process.
Ensure regulatory compliance

Software teams use DevSecOps to comply with regulatory requirements by adopting professional security practices and technologies. They identify data protection and security requirements in the system. For example, software teams use AWS Security Hub to automate security checks against industry standards.

Build a security-aware culture

Software teams become more aware of security best practices when developing an application. They are more proactive in spotting potential security issues in the code, modules, or other technologies for building the application.
Develop new features securely

DevSecOps encourages flexible collaboration between the development, operation, and security teams. They share the same understanding of software security and use common tools to automate assessment and reporting. Everyone focuses on ways to add more value to the customers without compromising on security.
**
How DevSecOps work?**

To implement DevSecOps, software teams must first implement DevOps and continuous integration.
DevOps

DevOps culture is a software development practice that brings development and operations teams together. It uses tools and automation to promote greater collaboration, communication, and transparency between the two teams. As a result, companies reduce software development time while still remaining flexible to changes.
Continuous integration

Continuous integration and continuous delivery (CI/CD) is a modern software development practice that uses automated build-and-test steps to reliably and efficiently deliver small changes to the application. Developers use CI/CD tools to release new versions of an application and quickly respond to issues after the application is available to users. For example, AWS CodePipeline is a tool that you can use to deploy and manage applications.
DevSecOps

DevSecOps introduces security to the DevOps practice by integrating security assessments throughout the CI/CD process. It makes security a shared responsibility among all team members who are involved in building the software. The development team collaborates with the security team before they write any code. Likewise, operations teams continue to monitor the software for security issues after deploying it. As a result, companies deliver secure software faster while ensuring compliance.

DevSecOps compared to DevOps

DevOps focuses on getting an application to the market as fast as possible. In DevOps, security testing is a separate process that occurs at the end of application development, just before it is deployed. Usually, a separate team tests and enforces security on the software. For example, security teams set up a firewall to test intrusion into the application after it has been built.

DevSecOps, on the other hand, makes security testing a part of the application development process itself. Security teams and developers collaborate to protect the users from software vulnerabilities. For example, security teams set up firewalls, programmers design the code to prevent vulnerabilities, and testers test all changes to prevent unauthorized third-party access.

Successful implementation of the DevSecOps practice consists of the following components.

Code analysis

Code analysis is the process of investigating the source code of an application for vulnerabilities and ensuring that it follows security best practices.
Change management

Software teams use change management tools to track, manage, and report on changes related to the software or requirements. This prevents inadvertent security vulnerabilities due to a software change.
Compliance management

Software teams ensure that the software complies with regulatory requirements. For example, developers can use AWS CloudHSM to demonstrate compliance with security, privacy, and anti-tamper regulations such as HIPAA, FedRAMP, and PCI.

Threat modeling

DevSecOps teams investigate security issues that might arise before and after deploying the application. They fix any known issues and release an updated version of the application.
Security training

Security training involves training software developers and operations teams with the latest security guidelines. This way, the development and operations teams can make independent security decisions when building and deploying the application.

Components of DevSecOps?

Code analysis

Code analysis is the process of investigating the source code of an application for vulnerabilities and ensuring that it follows security best practices.
Change management

DevSecOps teams investigate security issues that might arise before and after deploying the application. They fix any known issues and release an updated version of the application.
Security training

DevSecops Best Pratices

Shift left
Shift left is the process of checking for vulnerabilities in the earlier stages of software development. By following the process, software teams can prevent undetected security issues when they build the application. For example, developers create secure code in a DevSecOps process.
Shift right
Shift right indicates the importance of focusing on security after the application is deployed. Some vulnerabilities might escape earlier security checks and become apparent only when customers use the software.
Use automated security tools
DevSecOps teams might need to make multiple revisions in a day. To do that, they need to integrate security scanning tools into the CI/CD process. This prevents security evaluations from slowing down development.
Promote security awareness
Companies make security awareness a part of their core values when building software. Every team member who plays a role in developing applications must share the responsibility of protecting software users from security threats.

Resources

Watch video