Key Learnings from Cloud Academy’s Junior DevOps Job Role Path — Part II
Enjoy part 2 of my learnings!
If you haven’t already, here is part 1, where we discussed DevOps 101, Operations 101 and Monitoring 101, using AWS services.
This second part will cover the following topics:
- Shell Scripting Fundamentals (Includes hands-on lab)
- Container 101
- Container Orchestration with Docker (Includes hands-on lab)
- Container Orchestration with Kubernetes (Includes hands-on lab)
- Infrastructure as Code(IaC) (Includes hands-on lab)
- Infrastructure Security
- Final Thoughts…
Let’s dive in. This is a summary from my notes. The entire coursework from Cloud Academy can be found here
Shell Scripting Fundamentals
🧪CA includes hands-on lab to help you become a more effective Git user by working with top 10 Git Commands (for version control): Git Stash, Git Stash Pop, Git Blame, Git Diff, Reset, Checkout, Branch, Git Log, Show and Tag
Container 101
Why did containers originate?
The operating systems is the most resource-intensive piece of hardware on your computer; so running multiple OS’s on the same computer (for separate environments) uses a lot of resources. This is what led to the implemention of containers by Linux operating system.
A container is an isolated environment where an application runs without affecting the rest of the system and without the system impacting the application.
How to containerize an app?
- Containers work well when they are small and do 1 thing well (which brings us to microservices); general recommendation is to use 1 service per container
- It is possible to run microservices without using Containers however Containers make it possible to deploy microservices independently of their execution environment
- It is also worth noting that Microservices are about the design of software, whereas Containers are about packaging software for deployment
There’s a framework for building containerized microservice apps that a lot of businesses use. This is called the 12-Factor Application Framework. You can read about it here: https://12factor.net/
Container Orchestration with Docker
Let’s clear up things that can get you confused or rather, let me list out things that got me confused when I initially started out!
Docker vs container: Docker is one of the first, most successful and popular container software projects
A correlation that greatly helped me: container image = docker image, container registry = Docker hub, container host = docker host
Image vs Dockerfile: The Dockerfile contains all the instructions to build the image. From the dockerfile, you can run the image inside a container, or copy it to multiple times, to run it in as many containers as you want
Image vs Container: A Docker image presents a picture of a particular environment, whereas a Docker container is responsible for running the entire software
🧪Hands-on Lab included where within the AWS console, you:
- Install Docker on Linux using an AWS virtual machine
- Add a user to the Docker group
- Find and use images from the public Docker Registry
- Build your own images using Dockerfiles
Container Orchestration with Kubernetes
Kubernetes is an open source container orchestration system to manage multiple containers effortless and is cloud agnostic.
How does Kubernetes operate?
Cluster control plane aka the brain of the Kubernetes cluster
It is responsible for managing the overall state of the cluster. It containes the following key components:
- Kube API Server: handles RESTful requests and updates the cluster state
- etcd: highly-available key-value store used for cluster data
- Kube Scheduler: distributes workloads across nodes
- Cloud Controller Manager: manages interactions with cloud providers
Nodes: These are worker machines in Kubernetes, which can be either physical or virtual. They contain the necessary services to run pods and are managed by the control plane. Key components of nodes are:
- kubelet (ensures containers in pods run as expected)
- kube proxy (maintains network rules for pod communication)
Nodes and clusters are fundamental concepts in Kubernetes, and understanding their relationship is crucial.
Nodes vs Clusters
A cluster in Kubernetes is a set of nodes grouped together to work as a single system for running containerized applications. It provides a unified environment for deploying, managing, and scaling applications.
A node is a single machine (physical or virtual) within a Kubernetes cluster that runs the workloads. Each node contains the services necessary to run pods, which are the smallest deployable units in Kubernetes.
Pods
Pods are the smallest deployable units in Kubernetes (within nodes), consisting of one or more containers. They are ephemeral, but persistent storage can be configured. Services run on pods and jobs creates pod until completion.
🧪Hands-on Lab included where within the AWS console, you:
- Deploy a stateless application in a Kubernetes cluster
- Create a Kubernetes service to allow access to the application from outside the cluster
- Effectively manage Kubernetes clusters from the command-line
Infrastructure as Code(IaC)
3️⃣Superpowers of IaC in DevOps:
- Automating Consistenty — eliminates the need to manually maintain deployment environment settings. DevOps teams will often use infrastructure as code early in the development cycle to produce environments that mirror production. These environments are then used to test applications
- Idempotency: Ensuring Reliability — Idempotency means that running the same script multiple times will produce the same result, without unintended changes
- Streamlined Development and Testing — By using IaC, DevOps teams can quickly spin up and tear down test environments. This agility not only speeds up the development process but also allows for more thorough testing
Infrastructure Security
DevOps need to build cloud infrastructures that are secure by design. This is where frameworks such as CSSLP Domain 4.1 can come handy. DevOps teams should be able to understand and identify Common Software Vulnerabilities and Countermeasures.
For instance, the SANS Institute’s Top 25 Most Dangerous Software Errors provides insights into the most common and severe vulnerabilities that can affect software systems. Another popular vulnerability information sources is the OWASP Top 10 (also an independent global community of web security professionals and developers).
Attack types include:
- injection style — oldest and most prevalent types of security vulnerabilities;occurs when an attacker supplies untrusted input to a program (eg. SQL injection, XSS)
- cyrptographic failures — can compromise the security of systems by failing to protect sensitive data (e.g.hard-coded credentials, missing encryption for sensitive data)
Understanding these vulnerabilities helps in designing more secure systems and applying appropriate mitigation strategies.
Final Thoughts…
Overall, I found this Jr DevOps engineer job role path to be insightful and it was a good next step to study after my Solution Architect cloud certs. Also, my AWS SAA and Azure Solution Architect (definitely) helped me grasp conceps quicker (you can read about how I earned my AWS SAA certificate here). Favorite things about this coursework:
- Excellent visuals and animation to drive home important points
- Ease of accessing hands-on AWS labs — 💖 by far my favorite part of CA. You no longer need to worry about logging into cloud console with your MFA, exceeding cost by accidendantly clicking on a service, etc. Just get the bridge connected from your Cloud Academy portal and get going!
The outline of this coursework is great.
However, areas of improvement would be adding better flow to content (within topic headers). I also found certain topics to be repetitive. Not a biggie, especially if you are already familiar with the topics discussed. My verdict, go for it!
⭐⭐⭐ Keep going, keep growing!⭐⭐⭐
