♾ DevOps Tools - Setup, Installations, Guides ⚙️

🔗Link: https://github.com/NotHarshhaa/DevOps_Setup-Installations

We add daily Tools Setup, Installations, Guides with each and every commands with clear explanation

💎 Now added : Kubernetes, Jenkins, Ansible, Terraform, AWS, Azure, Linux
More added daily so fork the repository for updates

🐱 Follow me on GitHub for more DevOps/Cloud related sources


✈️ 𝗙𝗼𝗹𝗹𝗼𝘄 @prodevopsguy 𝗳𝗼𝗿 𝗺𝗼𝗿𝗲 𝘀𝘂𝗰𝗵 𝗰𝗼𝗻𝘁𝗲𝗻𝘁 𝗮𝗿𝗼𝘂𝗻𝗱 𝗰𝗹𝗼𝘂𝗱 & 𝗗𝗲𝘃𝗢𝗽𝘀!!! // Join for DevOps DOCs: @devopsdocs

➡️ Repository Update 📣


➡️Added Jenkins installation and setup and integrating for various types of tools to support your continuous integration and continuous deployment (CI/CD) pipelines

➡️ Here are tools content:

🔢. Version Control & Build Tools
🔢. Testing Frameworks Tools
🔢. Containerization Tools
🔢. Infrastructure as Code (IaC) Tools
🔢. Code Quality and Analysis Tools
🔢. Deployment Tools
🔢. Notification and Collaboration Tools

✈️ 𝗙𝗼𝗹𝗹𝗼𝘄 @prodevopsguy 𝗳𝗼𝗿 𝗺𝗼𝗿𝗲 𝘀𝘂𝗰𝗵 𝗰𝗼𝗻𝘁𝗲𝗻𝘁 𝗮𝗿𝗼𝘂𝗻𝗱 𝗰𝗹𝗼𝘂𝗱 & 𝗗𝗲𝘃𝗢𝗽𝘀!!! // Join for DevOps DOCs: @devopsdocs

💡 Kubernetes vs Docker: What's The Difference?

➡️Docker and Kubernetes are the most common names that one might hear in the field of container technology.

➡️Docker is a runtime and containerization platform that was first introduced in 2013 and brought about a microservices-based computing model.

➡️Kubernetes is a platform that manages and runs containers from multiple container runtimes and supports various container runtimes, including Docker.


❤️ 𝗙𝗼𝗹𝗹𝗼𝘄 @prodevopsguy 𝗳𝗼𝗿 𝗺𝗼𝗿𝗲 𝘀𝘂𝗰𝗵 𝗰𝗼𝗻𝘁𝗲𝗻𝘁 𝗮𝗿𝗼𝘂𝗻𝗱 𝗰𝗹𝗼𝘂𝗱 & 𝗗𝗲𝘃𝗢𝗽𝘀!!! // Join for DevOps DOCs: @devopsdocs

📢 Node Affinity

🔣 In Kubernetes, node affinity is a feature that allows you to control which nodes your pods are scheduled on based on labels on the node. This can be useful for various reasons such as optimizing performance, ensuring certain workloads are placed on specific nodes, or ensuring high availability by spreading pods across different nodes.

There are two types of node affinity:
🔎 Required Node Affinity: This type specifies that a pod should only be scheduled on nodes that meet the specified node selector requirements.

🔎 Preferred Node Affinity: This type specifies that a pod prefers to be scheduled on nodes that meet the specified node selector requirements, but it can still be scheduled on nodes that do not meet those requirements.


🌐 𝗙𝗼𝗹𝗹𝗼𝘄 @prodevopsguy 𝗳𝗼𝗿 𝗺𝗼𝗿𝗲 𝘀𝘂𝗰𝗵 𝗰𝗼𝗻𝘁𝗲𝗻𝘁 𝗮𝗿𝗼𝘂𝗻𝗱 𝗰𝗹𝗼𝘂𝗱 & 𝗗𝗲𝘃𝗢𝗽𝘀!!! // Join for DevOps DOCs: @devopsdocs

🔴 A nice cheat sheet of different cloud services.

➡️ What’s included?
- AWS, Azure, Google Cloud, Oracle Cloud, Alibaba Cloud
- Cloud servers
- Databases
- Message queues and streaming platforms
- Load balancing, DNS routing software
- Security
- Monitoring


😎 𝗙𝗼𝗹𝗹𝗼𝘄 @prodevopsguy 𝗳𝗼𝗿 𝗺𝗼𝗿𝗲 𝘀𝘂𝗰𝗵 𝗰𝗼𝗻𝘁𝗲𝗻𝘁 𝗮𝗿𝗼𝘂𝗻𝗱 𝗰𝗹𝗼𝘂𝗱 & 𝗗𝗲𝘃𝗢𝗽𝘀!!! // Join for DevOps DOCs: @devopsdocs

https://blog.prodevopsguy.xyz/the-ultimate-devops-bootcamp-2024-pack-by-prodevopsguy

⚠️ Note: Anyone Interested, can open the Blog 🌐, share it to your friends and colleagues.


🔵 𝗙𝗼𝗹𝗹𝗼𝘄 @prodevopsguy 𝗳𝗼𝗿 𝗺𝗼𝗿𝗲 𝘀𝘂𝗰𝗵 𝗰𝗼𝗻𝘁𝗲𝗻𝘁 𝗮𝗿𝗼𝘂𝗻𝗱 𝗰𝗹𝗼𝘂𝗱 & 𝗗𝗲𝘃𝗢𝗽𝘀!!!

🔣 Docker is a powerful tool that allows you to package your application and its dependencies into a standardized unit called a container.

👉 𝗛𝗲𝗿𝗲'𝘀 𝗮 𝗯𝗿𝗲𝗮𝗸𝗱𝗼𝘄𝗻 𝗼𝗳 𝗵𝗼𝘄 𝗗𝗼𝗰𝗸𝗲𝗿 𝘄𝗼𝗿𝗸𝘀:

➡️𝗗𝗼𝗰𝗸𝗲𝗿 𝗰𝗼𝗻𝘁𝗮𝗶𝗻𝗲𝗿𝘀 are self-contained units that package your application code, runtime, system tools, settings, and libraries. They're like tiny virtual machines, but they share the underlying operating system kernel with other containers, making them much more lightweight and efficient.

➡️𝗗𝗼𝗰𝗸𝗲𝗿 𝗶𝗺𝗮𝗴𝗲𝘀 are blueprints that contain instructions for creating containers. They're kind of like recipes that tell Docker how to build a container with all the necessary ingredients. You can find and share images on public registries like Docker Hub, or create your custom images.

➡️𝗗𝗼𝗰𝗸𝗲𝗿 𝗱𝗮𝗲𝗺𝗼𝗻 (𝗱𝗼𝗰𝗸𝗲𝗿𝗱) is the engine that builds, runs, and manages Docker containers. It's the behind-the-scenes workhorse that makes everything tick.

➡️𝗗𝗼𝗰𝗸𝗲𝗿 𝗰𝗹𝗶𝗲𝗻𝘁 (𝗱𝗼𝗰𝗸𝗲𝗿 𝗖𝗟𝗜) is the tool you use to interact with the Docker daemon. It allows you to build, run, stop, and manage your containers using commands or a graphical user interface (GUI).

➡️𝗗𝗼𝗰𝗸𝗲𝗿 𝗿𝗲𝗴𝗶𝘀𝘁𝗿𝗶𝗲𝘀 are repositories that store and share Docker images. Think of them as libraries for Docker images. Docker Hub is the most popular public registry, but there are also private registries that organizations can use to store their custom images.

➡️𝗗𝗼𝗰𝗸𝗲𝗿 𝘀𝘁𝗼𝗿𝗮𝗴𝗲 𝗱𝗿𝗶𝘃𝗲𝗿𝘀 manage how data is stored and persisted within containers. The default storage driver is overlay2, but there are other options available, such as aufs, zfs, and btrfs.

➡️𝗖𝗼𝗻𝘁𝗮𝗶𝗻𝗲𝗿 𝗼𝗿𝗰𝗵𝗲𝘀𝘁𝗿𝗮𝘁𝗼𝗿𝘀 like Kubernetes and Swarm are tools that help you manage and scale large deployments of Docker containers. They take care of provisioning, scheduling, and healing your containers, making it easier to run complex applications in production.


😎 𝗙𝗼𝗹𝗹𝗼𝘄 @prodevopsguy 𝗳𝗼𝗿 𝗺𝗼𝗿𝗲 𝘀𝘂𝗰𝗵 𝗰𝗼𝗻𝘁𝗲𝗻𝘁 𝗮𝗿𝗼𝘂𝗻𝗱 𝗰𝗹𝗼𝘂𝗱 & 𝗗𝗲𝘃𝗢𝗽𝘀!!! // Join for DevOps DOCs: @devopsdocs

📌 https://harshhaa.hashnode.dev/real-time-devops-project-deploy-to-kubernetes-using-jenkins-end-to-end-devops-project-cicd

🔗 More DevOps Projects : HERE

🔥🔥🔥🔥🔥🔥🔥🔥

Follow 🍩 Like 👍 Share 👍 Comment Your thoughts 💬

⭐️ 𝗙𝗼𝗹𝗹𝗼𝘄 @prodevopsguy & @devopsdocs 𝗳𝗼𝗿 𝗺𝗼𝗿𝗲 𝘀𝘂𝗰𝗵 𝗰𝗼𝗻𝘁𝗲𝗻𝘁 𝗮𝗿𝗼𝘂𝗻𝗱 𝗰𝗹𝗼𝘂𝗱 & 𝗗𝗲𝘃𝗢𝗽𝘀!!!

👍 Multi-Stage Build Images used in CICD ♾

➡️ Every microservice should be its own separate container. If you only use a single-stage Docker build, you’re probably missing out on some powerful features of the build process. On the other hand, a multi-stage Docker build has many advantages over a single-stage build for deploying microservices.

➡️ Some Advantages are :
- Optimizes the overall size of the Docker image
- Removes the burden of creating multiple Dockerfiles for different stages
- Easy to debug a particular build stage
- Able to use the previous stage as a new stage in the new environment
- Ability to use the cached image to make the overall process quicker
- Reduces the risk of vulnerabilities found as the image size becomes smaller with multi-stage builds


😎 𝗙𝗼𝗹𝗹𝗼𝘄 @prodevopsguy 𝗳𝗼𝗿 𝗺𝗼𝗿𝗲 𝘀𝘂𝗰𝗵 𝗰𝗼𝗻𝘁𝗲𝗻𝘁 𝗮𝗿𝗼𝘂𝗻𝗱 𝗰𝗹𝗼𝘂𝗱 & 𝗗𝗲𝘃𝗢𝗽𝘀!!! // Join for DevOps DOCs: @devopsdocs

🐬 Docker Container Commands for a DevOps Engineer

The below illustration shows some common container commands and their syntax 👇

1. 🏗 Creates a container from an image

docker run -it --name nginx nginx

2. 🚀 Begins a Docker container

docker start nginx

3. 🔄 Restarts a Docker container.

docker restart nginx

4. ⏸ Temporarily halts a container.

docker pause nginx

5. ▶️ Resumes a paused container.

docker unpause nginx

6. 🛑 Ends a running Docker container.

docker stop nginx

7. ❌ Forcefully stops a running container

docker kill nginx

8. 📊 Lists Docker containers.

docker ps

9. 🖥 Accesses a container's shell.

docker exec -it nginx /bin/bash

10. 📝 Connects to a running container.

docker attach nginx

11. 📜 Views container logs.

docker logs nginx

12. 🔄 Change a container's name.

docker rename old-name new-name

13. 🔍 Retrieves container info.

docker inspect nginx

14. 📂 Copies files to/from a container.

docker cp nginx:/container-path/file.txt /local-path

15. 🗑 Deletes a container.

docker rm nginx

These container commands are essential for managing containerized applications, whether for development, testing, or production deployment, as they enable efficient control and manipulation of container instances.


😎 𝗙𝗼𝗹𝗹𝗼𝘄 @prodevopsguy 𝗳𝗼𝗿 𝗺𝗼𝗿𝗲 𝘀𝘂𝗰𝗵 𝗰𝗼𝗻𝘁𝗲𝗻𝘁 𝗮𝗿𝗼𝘂𝗻𝗱 𝗰𝗹𝗼𝘂𝗱 & 𝗗𝗲𝘃𝗢𝗽𝘀!!! // Join for DevOps DOCs: @devopsdocs

From 'It works on my machine!' to 'It works on my container!' but hey at least it works!


✔️ 𝗙𝗼𝗹𝗹𝗼𝘄 @prodevopsguy 𝗳𝗼𝗿 𝗺𝗼𝗿𝗲 𝘀𝘂𝗰𝗵 𝗰𝗼𝗻𝘁𝗲𝗻𝘁 𝗮𝗿𝗼𝘂𝗻𝗱 𝗰𝗹𝗼𝘂𝗱 & 𝗗𝗲𝘃𝗢𝗽𝘀!!!

⚙️ Interested in mastering security practices? Let's embark on your DevSecOps ♾ journey

𝐁𝐢𝐠 𝐨𝐧 𝐝𝐞𝐯𝐞𝐥𝐨𝐩𝐦𝐞𝐧𝐭? ▶️ Jenkins identifies issues early.
𝐍𝐚𝐯𝐢𝐠𝐚𝐭𝐢𝐧𝐠 𝐜𝐨𝐦𝐩𝐥𝐢𝐚𝐧𝐜𝐞 𝐜𝐡𝐚𝐥𝐥𝐞𝐧𝐠𝐞𝐬? ▶️ DevSecOps ensures stability.
𝐇𝐢𝐭 𝐚 𝐬𝐲𝐬𝐭𝐞𝐦 𝐟𝐚𝐢𝐥𝐮𝐫𝐞? ▶️ Jenkins guides us back on course.
𝐇𝐢𝐝𝐝𝐞𝐧 𝐭𝐫𝐞𝐚𝐬𝐮𝐫𝐞𝐬 𝐚𝐡𝐞𝐚𝐝 - 𝐜𝐨𝐬𝐭 𝐬𝐚𝐯𝐢𝐧𝐠𝐬! ▶️ Every efficient step counts.
𝐀𝐧𝐨𝐦𝐚𝐥𝐢𝐞𝐬? ▶️ Our AI-powered monitor remains vigilant.

Approaching the finish line, security risks arise, yet DevSecOps mitigates them, instilling confidence. Ultimately, complete awareness of potential threats.


😎 𝗙𝗼𝗹𝗹𝗼𝘄 @prodevopsguy 𝗳𝗼𝗿 𝗺𝗼𝗿𝗲 𝘀𝘂𝗰𝗵 𝗰𝗼𝗻𝘁𝗲𝗻𝘁 𝗮𝗿𝗼𝘂𝗻𝗱 𝗰𝗹𝗼𝘂𝗱 & 𝗗𝗲𝘃𝗢𝗽𝘀!!! // Join for DevOps DOCs: @devopsdocs

📌 Discuss scenarios in which you would prefer Docker Swarm over Kubernetes, or vice versa, for container orchestration 📌

Docker Swarm and Kubernetes are popular container orchestration tools that efficiently manage, scale and deploy containers. Each has its strengths and weaknesses, and understanding these can help you choose the right tool for your specific needs. Differences and scenarios where one might be preferred over the other

✅ Docker Swarm
➡️ Simplicity and Integration: Docker Swarm is known for its simplicity and ease of setup, especially for users already familiar with Docker. It's tightly integrated with Docker, meaning you can use Docker CLI commands to create a swarm, deploy applications, and manage nodes. This integration makes Swarm a more straightforward choice for smaller-scale applications or teams beginning with container orchestration.

➡️ How it works: Docker Swarm uses the standard Docker API, making it compatible with any Docker tool. Swarm managers can delegate tasks to worker nodes, automatically decide the optimal node for container deployment based on resource availability, and manage load balancing and scaling.

✅ Kubernetes
➡️ Complexity and Flexibility: Kubernetes is more complex than Docker Swarm but offers significantly more flexibility, features, and fine-grained control over containers. It supports a wide range of workloads, has extensive integration with cloud services, and has a vast ecosystem.

➡️ How it works: Kubernetes architecture includes a master node (control plane) and worker nodes. The control plane's components (API server, scheduler, etcd, controller manager, etc.) manage the state of the cluster, scheduling, and deployments based on user-defined desired states. Kubernetes uses etcd, a distributed key-value store, to keep the cluster state consistent.

🧐 Prefer Docker Swarm when:
1️⃣ You're looking for simplicity and faster deployment. Docker Swarm is easier to configure and manage, making it suitable for smaller teams or projects with simpler deployment needs.
2️⃣ You have a smaller-scale application or microservices that don't require the extensive features of Kubernetes.
3️⃣ Your team is already comfortable with Docker, and you want to leverage container orchestration without a steep learning curve.

🧐 Prefer Kubernetes when:
1️⃣ You need to manage large-scale, complex applications with high availability and many services. Kubernetes' advanced features and flexibility make it suitable for enterprise-level deployments.
2️⃣ You require advanced deployment strategies (like blue-green deployments, canary releases) and auto-scaling based on traffic or other metrics.
3️⃣ You're leveraging cloud-native technologies and services, as Kubernetes has extensive support from cloud providers and a vast ecosystem of tools and extensions.


😎 𝗙𝗼𝗹𝗹𝗼𝘄 @prodevopsguy 𝗳𝗼𝗿 𝗺𝗼𝗿𝗲 𝘀𝘂𝗰𝗵 𝗰𝗼𝗻𝘁𝗲𝗻𝘁 𝗮𝗿𝗼𝘂𝗻𝗱 𝗰𝗹𝗼𝘂𝗱 & 𝗗𝗲𝘃𝗢𝗽𝘀!!! // Join for DevOps DOCs: @devopsdocs

🔥 Ansible Commands which DevOps Engineers use on daily bases: 🔣

1. ansible-playbook: Executes Ansible playbooks.
ex: ansible-playbook -i <inventory_file> <playbook.yml>

2. ansible: Runs ad-hoc commands or tasks.
ex: ansible all -m copy -a "src=/path/to/local/file dest=/path/to/remote/file"
ansible all -m yum -a "name=httpd state=latest"

3. ansible-galaxy: Manages Ansible roles.
ex: ansible-galaxy install <role_name>

4. ansible-vault: Manages encrypted data within Ansible.
ex: ansible-vault encrypt <file>

5. ansible-galaxy init role_name: Initializes a new Ansible role scaffold.
ex: ansible-galaxy init <role_name>

6. ansible-inventory: Shows Ansible's inventory.
ex: ansible-inventory --list -i /path/to/inventory/hosts

7. ansible-config: Manages Ansible configuration.
ex: ansible-config list, ansible-config view

8. ansible-pull: Pulls playbooks from a version control system and executes them locally.
ex: ansible-pull -U <repository_url> <playbook.yml>

9. ansible-playbook --syntax-check: Checks playbook syntax without executing.
ex: ansible-playbook --syntax-check <playbook.yml>

10. ansible-playbook --list-hosts: Lists hosts defined in a playbook.
ex: ansible-playbook --list-hosts playbook.yml

11. ansible-playbook --tags: Runs specific tagged tasks within a playbook.
ex: ansible-playbook --tags=tag1,tag2 playbook.yml

12. ansible-playbook --limit: Limits playbook execution to specific hosts or groups.
ex: ansible-playbook --limit=<host_pattern> <playbook.yml>

13. ansible-vault edit: Edits an encrypted file.
ex: ansible-vault edit secrets.yml

14. ansible-doc: Displays documentation for Ansible modules.
ex: ansible-doc <module_name>

15. ansible-config view: Displays the current Ansible configuration.
ex: ansible-config view

16. ansible-config dump: Dumps the current Ansible configuration variables.
ex: ansible-config dump

17. ansible-config list: Lists configuration settings.
ex: ansible-config list

18. ansible-console: Starts an interactive console for executing Ansible tasks.
ex: ansible-console

19. ansible-lint: Lints Ansible playbooks for best practices and potential errors.
ex: ansible-lint <playbook.yml>

20. ansible-vault encrypt_string: Encrypts a string for use in a playbook.
ex: ansible-vault encrypt_string <string>

21. ansible-vault rekey: Rekeys an encrypted file with a new password.
ex: ansible-vault rekey <file>


⭐️ 𝗙𝗼𝗹𝗹𝗼𝘄 @prodevopsguy & @devopsdocs 𝗳𝗼𝗿 𝗺𝗼𝗿𝗲 𝘀𝘂𝗰𝗵 𝗰𝗼𝗻𝘁𝗲𝗻𝘁 𝗮𝗿𝗼𝘂𝗻𝗱 𝗰𝗹𝗼𝘂𝗱 & 𝗗𝗲𝘃𝗢𝗽𝘀!!!

📌 Exercise Caution When Utilizing the drop_cache 📌

Instead of just looking at the available memory in the free -m output, some users might panic and quickly run the drop_cache command. I strongly advise against doing so.

💻 The command "echo 3 > /proc/sys/vm/drop_cache" is used to clear the disk cache in Linux.

⏩ The different options for the drop_cache command:

🔹 Option 1:
➡️ Command: echo 1 > /proc/sys/vm/drop_cache
➡️ Effect: This option clears the page cache only. It removes unused pages, making more memory available right away.

🔹 Option 2:
➡️ Command: echo 2 > /proc/sys/vm/drop_cache
➡️ Effect: This option clears the directory and file metadata cache. It frees up space used for file information, resulting in faster access to directories and file details.

🔹 Option 3:
➡️ Command: echo 3 > /proc/sys/vm/drop_cache
➡️ Effect: This option combines the effects of options 1 and 2. It clears the page cache and the directory/file metadata cache, providing a more thorough clearing of cached data.

🚨 It's important to note that running these commands requires administrative privileges (root access). It's also worth mentioning that clearing the disk cache using the drop_cache command is usually done in specific cases, such as optimizing system performance, troubleshooting issues, or testing. Clearing the cache without a valid reason may temporarily slow down your system until the cache is filled with relevant data again.

🎬 Always exercise caution and understand the implications before using these commands.


😎 𝗙𝗼𝗹𝗹𝗼𝘄 @prodevopsguy 𝗳𝗼𝗿 𝗺𝗼𝗿𝗲 𝘀𝘂𝗰𝗵 𝗰𝗼𝗻𝘁𝗲𝗻𝘁 𝗮𝗿𝗼𝘂𝗻𝗱 𝗰𝗹𝗼𝘂𝗱 & 𝗗𝗲𝘃𝗢𝗽𝘀!!! // Join for DevOps DOCs: @devopsdocs

❤️‍🔥 𝐓𝐡𝐞 𝐓𝐞𝐫𝐫𝐚𝐟𝐨𝐫𝐦 𝐂𝐋𝐈 𝐂𝐡𝐞𝐚𝐭 𝐒𝐡𝐞𝐞𝐭 🚀

Terraform is an infrastructure as a code tool that lets you build, change, and version infrastructure safely and efficiently.


😎 𝗙𝗼𝗹𝗹𝗼𝘄 @prodevopsguy 𝗳𝗼𝗿 𝗺𝗼𝗿𝗲 𝘀𝘂𝗰𝗵 𝗰𝗼𝗻𝘁𝗲𝗻𝘁 𝗮𝗿𝗼𝘂𝗻𝗱 𝗰𝗹𝗼𝘂𝗱 & 𝗗𝗲𝘃𝗢𝗽𝘀!!! // Join for DevOps DOCs: @devopsdocs

📌 𝐓𝐨𝐩 𝐊𝐮𝐛𝐞𝐫𝐧𝐞𝐭𝐞𝐬 '𝐘𝐚𝐦𝐥' 𝐯𝐚𝐥𝐢𝐝𝐚𝐭𝐢𝐨𝐧 𝐭𝐨𝐨𝐥𝐬 & 𝐢𝐭'𝐬 𝐮𝐬𝐚𝐠𝐞 ☸️ 🛠

👉 𝐂𝐨𝐧𝐟𝐭𝐞𝐬𝐭 (https://lnkd.in/gfBYcnGM)
✍️ Provides a testing framework for developers to check and verify hashtag#k8s resources to validate against Kubernetes configuration. Users can easily write tests for hashtag#serverless, hashtag#Terraform and other prominent frameworks

👉 𝐊𝐮𝐛𝐞𝐜𝐨𝐧𝐟𝐨𝐫𝐦 (https://lnkd.in/g6fm4vHY)
✍️ Tool that validates manifests using the official hashtag#Kubernetes hashtag#OpenAPI specifications on the server side

👉 𝐊𝐮𝐛𝐞𝐥𝐢𝐧𝐭𝐞𝐫 (https://lnkd.in/gV95CqFh)
✍️ Analyzes Kubernetes YAML files and Helm charts, checks them against a variety of best practices, with a focus on production readiness and security

👉 𝐘𝐚𝐦𝐥𝐥𝐢𝐧𝐭 (https://lnkd.in/g-uqstAc)
✍️ Validate, verify and reformat yaml documents, checking cosmetic problems such as lines length, trailing spaces, indentation

👉 𝐂𝐨𝐩𝐩𝐞𝐫 (https://lnkd.in/ftSQcA4)
✍️ Checks configuration files through custom checks through helper functions written in javascript. Enforces best practices, apply policies and compliance requirements

👉 C𝐨𝐧𝐟𝐢𝐠-𝐥𝐢𝐧𝐭 (https://lnkd.in/gSaCEuWU)
✍️ CLI tool to validate configuration files using rules specified in YAML. The configuration files can be one of several formats: Terraform, JSON, YAML, with support for Kubernetes

👉 𝐊𝐮𝐛𝐞-𝐬𝐜𝐨𝐫𝐞 (https://lnkd.in/gAvzn_WE)
✍️ Tool that performs static code analysis of k8s object definitions. The output is list of recommendations of what you can improve to make the application more secure and resilient

👉 𝐂𝐡𝐚𝐫𝐭-𝐭𝐞𝐬𝐭𝐢𝐧𝐠 (https://lnkd.in/gKM-9bQm)
✍️ Tool for testing Helm charts that is used for linting and testing pull requests. It automatically detects charts changed against the target branch

👉 𝐊𝐥𝐢𝐧𝐭 (https://lnkd.in/gnFsWfkw)
✍️ Listens to changes in Kubernetes resources and runs linting rules against them. Alerts are published via Slack webhooks to a configurable channel

👉 𝐊𝐮𝐛𝐞𝐯𝐢𝐨𝐮𝐬 𝐂𝐋𝐈 (https://lnkd.in/fyqqp9U)
✍️ Standalone tool that validates YAML manifests for syntax, semantics, conflicts, compliance and security best practices violations. Can be easily used during active development and integrated into hashtag#GitOps processes and CI/CD pipelines to validate changes toward live Kubernetes clusters


😎 𝗙𝗼𝗹𝗹𝗼𝘄 @prodevopsguy 𝗳𝗼𝗿 𝗺𝗼𝗿𝗲 𝘀𝘂𝗰𝗵 𝗰𝗼𝗻𝘁𝗲𝗻𝘁 𝗮𝗿𝗼𝘂𝗻𝗱 𝗰𝗹𝗼𝘂𝗱 & 𝗗𝗲𝘃𝗢𝗽𝘀!!! // Join for DevOps DOCs: @devopsdocs

📌 Differences Between AWS EC2 Instance: Start, Stop, and Restart Operation 📌

Many of us who use AWS often stop, start, or restart instances. However, only some realize differences in how these operations work.

🔄 Instance Reboot:
A reboot is equivalent to a restart operation on a traditional physical machine. It keeps the instance on the same host machine unless the host is unhealthy or has other problems. The instance keeps the same public and private IP addresses, and any data on the instance store volumes and Elastic Block Store (EBS) volumes remains intact.

❓How does it work
When a reboot command is initiated, the hypervisor sends a signal to the guest operating system to perform a soft reboot, which is a more graceful way to restart the system. The operating system will stop all running processes, flush any cached data to disk, and restart.

🛑 Instance Shutdown (Stop):
Stopping an instance is like shutting down a physical machine. The instance is powered down and no longer running, so you're not billed for additional instance hours. The instance retains its instance ID, but all data in the instance store volumes is lost. The public IP address is released when the instance is stopped (unless associated with an Elastic IP), but the private IP address remains associated. When the instance is started again, it might be run on a different host machine.

❓How does it work
When a stop command is initiated, the hypervisor sends a signal to the guest operating system to perform a soft shutdown, which is a more graceful way to shut down the system. All the processes will be stopped, and any cached data will be written to disk. After that, the hypervisor will deallocate the previously allocated resources to the instance.

😎 𝗙𝗼𝗹𝗹𝗼𝘄 @prodevopsguy 𝗳𝗼𝗿 𝗺𝗼𝗿𝗲 𝘀𝘂𝗰𝗵 𝗰𝗼𝗻𝘁𝗲𝗻𝘁 𝗮𝗿𝗼𝘂𝗻𝗱 𝗰𝗹𝗼𝘂𝗱 & 𝗗𝗲𝘃𝗢𝗽𝘀!!! // Join for DevOps DOCs: @devopsdocs