Blog NivelEpsilon

Basic Linux Proficiency for Aspiring DevOps Engineers

In the ever-evolving landscape of DevOps, Linux proficiency is like a trusty Swiss Army knife. It’s a versatile tool that empowers DevOps engineers to navigate the complex terrain of automation, continuous integration, and deployment with finesse. In this article, we’ll delve into the essential Linux knowledge areas that will help you unlock your DevOps potential.

1. Mastering the Linux File System

Before you can dance to the DevOps tune, you need to understand the stage – the Linux file system. At its core lies the root directory (“/”) and subdirectories like “/etc/”, “/var/”, “/home/”, and “/bin/”. These directories house critical system and user data.

Understanding file types is crucial. Regular files, directories, symbolic links, and device files are your basic cast members. Navigating this ecosystem requires knowledge of absolute and relative paths. The PATH variable determines where the system hunts for executable files, so it’s a vital setting to comprehend.

When it comes to file permissions, the DevOps engineer must be a maestro. User, group, and other permissions govern who can do what with a file. Commands like chmod, chown, and chgrp allow you to conduct the permissions orchestra.

# Create a directory called "project" in the current directory
mkdir project

# Change the permissions of the "my_file.txt" so that all users can read and write it
chmod a+rw my_file.txt

# View the directory structure in the current directory
ls

2. Command-Line Essentials

The command line is your DevOps console, and you need to be fluent in its dialect. Commands like ls, cd, cat, echo, mkdir, and rm are your basic vocabulary. They help you explore, manipulate, and create files and directories.

For more advanced operations, you’ll want to wield cp, mv, find, tar, and zip to handle files efficiently. When it comes to text manipulation, don’t leave home without grep, awk, sed, and cut – they’re your linguistic tools for parsing and processing.

Networking utilities like netstat, ifconfig (or ip), curl, and ping are essential for troubleshooting connectivity and network-related issues.

# Create a text file named "greeting.txt" with the content "Hello, World!"
echo "Hello, World!" > greeting.txt

# Display the contents of the "greeting.txt" file on the screen
cat greeting.txt

# Copy the "source_file.txt" to a directory named "copy"
cp source_file.txt copy/

3. Package Management

Different Linux distributions come with their own package managers. Whether you’re on Debian/Ubuntu (apt-get or apt), RedHat/CentOS (yum or dnf), or SUSE (zypper), you need to know how to install, remove, and update packages. This is the key to maintaining a well-oiled system.

# Install the "apache2" package on a Debian/Ubuntu-based system
sudo apt-get install apache2

# Remove the "nginx" package on a RedHat/CentOS-based system
sudo yum remove nginx

# Update all packages on a SUSE-based system
sudo zypper update

4. Process Management

In the DevOps theater, processes take center stage. You need to know how to list, kill, and prioritize them. Commands like ps, top, htop, and kill are your props for managing processes effectively.

# Display a real-time sorted view of system processes
top

# View a list of processes with details, including Process IDs (PIDs)
ps aux | grep process_name

# Terminate a specific process by its Process ID (PID)
kill PID

5. The Art of VI

VI is your text editor of choice, and it’s available on virtually every UNIX system. It may seem cryptic at first, with its modes (Normal, Insert, Command), but once you’re proficient, you’ll appreciate its power for editing configuration files and scripts.

# Open the "configuration_file.conf" file in edit mode with VI
vi configuration_file.conf

# Enter Insert mode to add text
i

# Save changes and exit the editor
:wq

# Exit the editor without saving changes
:q!

6. User and Group Mastery

As a DevOps engineer, you’re often tasked with user and group management. Useradd, usermod, groupadd, and friends are your tools. Understanding the /etc/passwd and /etc/group files is crucial for managing user accounts and groups effectively.

# Add a new user named "new_user" with a home directory
sudo useradd -m new_user

# Modify the login shell of "new_user" to /bin/bash
sudo usermod -s /bin/bash new_user

# Create a new group named "new_group"
sudo groupadd new_group

# Add the user "new_user" to the "new_group"
sudo usermod -aG new_group new_user

7. Shell Scripting

DevOps automation often involves scripting, and bash is your scripting language of choice. You need to be comfortable with variables, loops, and conditional statements to automate tasks effectively.

# Basic script that displays a message if the user is "admin"
#!/bin/bash
user="admin"
if [ "$USER" == "$user" ]; then
  echo "Welcome, $user!"
fi

8. Root and Sudo

With great power comes great responsibility. The root user has unrestricted access, but it’s also risky. Use sudo (superuser do) to execute commands with elevated privileges safely. Editing the sudoers file is a delicate operation; use visudo to avoid issues.

# Execute a command with superuser privileges
sudo command

# Safely edit the sudoers file
sudo visudo

9. Log Exploration

Log files are your breadcrumbs when troubleshooting. You need to know where they’re stored (/var/log/) and how to read them using tools like less, tail, and head.

# View the last 20 entries in a log file
tail -n 20 /var/log/log_file.log

# View the first 10 entries in a log file
head -n 10 /var/log/log_file.log

10. Networking Basics

Understanding IP addressing, subnets, ports, and protocols is essential. Configure and manage network interfaces, routes, and firewall rules using tools like iptables and files like /etc/network/interfaces.

# View the current network configuration, including active interfaces
ifconfig

# Show all configured network routes on the system
ip route show

# Create a firewall rule to allow traffic on port 80 (HTTP)
sudo iptables -A INPUT -p tcp --dport 80 -j ACCEPT

11. Secure Shell (SSH)

Remote management is a fundamental skill in DevOps. Use SSH for secure remote login and SCP for file transfer. Master SSH key generation and configuration for secure access.

# Generate a pair of SSH keys (public and private)
ssh-keygen -t rsa -b 2048

# Copy the public key to the remote server for authentication
ssh-copy-id user@remote_server

# Log in to the remote server using SSH
ssh user@remote_server

12. Disk and Storage

It’s important to know how to view disk usage (df, du), manage partitions and file systems (fdisk, mkfs), and mount/unmount storage devices.

# View the amount of used and available disk space on mounted file systems
df -h

# Estimate disk space usage for a specific directory
du -sh directory/

# Create a new partition on a disk using fdisk
sudo fdisk /dev/sdX

# Format a partition to a specific file system
sudo mkfs -t ext4 /dev/sdX1

# Mount a storage device to a specific directory
sudo mount /dev/sdX1 /mnt/mount_point

# Unmount a previously mounted storage device
sudo umount /mnt/mount_point

In summary, Linux is your foundation as a DevOps engineer. These skills are your stepping stones to becoming a virtuoso in DevOps. As you navigate the ever-changing DevOps landscape, remember that Linux is your trusted guide, leading you towards mastery in automation and success in continuous deployment. Happy DevOps engineering!

DevOps or a Different Path?


The world of technology is ever-evolving, with endless opportunities and career paths. If you’re considering a career in technology, you face a fundamental choice: Should you opt for DevOps, or explore alternatives? Let’s navigate these options and consider which path might be right for you.

The Allure of DevOps

Let’s begin with DevOps, a discipline that combines development and operations to deliver software efficiently. DevOps is exciting, offers significant growth potential, and is in high demand in the industry. If you love automation, problem-solving, and working in teams, DevOps might be a tempting path.

The Challenge of Continuous Learning

However, an essential aspect of DevOps is continuous learning. As technologies evolve, DevOps engineers must stay up-to-date. This may require time outside of working hours and a constant commitment to skill improvement. Don’t forget this !!

Exploring Alternatives

On the other hand, the world of technology offers a variety of options. You can consider roles in software development, cybersecurity, data analysis, artificial intelligence, and more. Each of these fields has its own set of challenges and rewards.

The Importance of Your Passions and Skills

The choice between DevOps and alternatives should be based on your interests and skills. Are you passionate about cybersecurity? Perhaps cybersecurity is your path. Are you drawn to programming? Software development might be your best choice. Evaluate your strengths and weaknesses and consider what aspects you enjoy most in technology.

The Flexibility of Your Career

It’s important to remember that your initial choice doesn’t have to be permanent. Technology is a flexible field, and you can change your course as you discover more about your preferences and goals. Many technology professionals have shifted specialties throughout their careers.

My humble opinion

Ultimately, the choice between DevOps and technology alternatives is a personal decision. Assess your interests, skills, and willingness for continuous learning. No matter which path you choose, technology will remain an exciting and ever-changing field.

So, go ahead, and navigate with confidence in this sea of technological opportunities. Whether you opt for DevOps or explore other paths, your technological journey will be an adventure filled with discoveries and professional growth, and good luck with your choice!

Advancements in Infrastructure Automation for Future DevOps Success.


I’ve been a bit reflective due to an IaC task that has become a bit more complex, thus taking me longer to complete than initially anticipated, and I’ve realized there are some aspects I believe have room for improvement. I believe that infrastructure automation and infrastructure state management still have room to mature in order to become more effective. While tools like Terraform and Ansible have come a long way, there are several areas where improvement is needed:

1. Greater Resilience and Enhanced Rollback: Infrastructure as Code (IaC) tools could advance by automatically detecting deployment failures and safely rolling back to a previous state without human intervention.

2. Tighter Integration with Cloud Services: IaC tools could integrate even more seamlessly with cloud services, simplifying the management of resources such as databases, load balancers, and container services, thereby streamlining the orchestration of complex infrastructures.

3. Advanced Secrets Management: Effective secrets management is critical in DevOps. IaC tools could enhance the way secrets are handled and stored, providing a more robust security layer and enabling automated secret rotation. I am aware that steps are currently being taken in this direction.

4. Predictive Analysis and Optimization: Tools utilizing predictive analytics to identify infrastructure bottlenecks or performance issues before they become actual problems, allowing for proactive optimization.

5. Improvements in Visualization and Monitoring: More advanced graphical interfaces and real-time monitoring tools that enable DevOps teams to understand and address issues more efficiently.

These are just a few examples IMHO of how maturing automation in infrastructure and state management could benefit DevOps teams in the future.

DevOps and Plaform engineers differences, is DevOps death? 

From my perspective DevOps is about combining development and operations into one coherent group or team capable of delivering applications from the initial concept all the way until production, and then, also making sure that it continues running in production right. I think it’s about creating those self-sufficient teams.

Platform engineering is about creating internal tooling, an internal platform that is tailor-made for the needs of a company that combines all the tools the company uses, and creates that abstraction layer on top that simplifies usage for everybody else.
A person might have seven years of experience in Terraform but it’s unrealistic to expect that everybody will know everything about it, and even more unrealistic that everybody will know everything about AWS, Azure, and so on, so Platform engineers are in charge of developing such internal tooling that simplifies specific processes in a company, and enables everybody else to do things instead of opening Jira tickets.

The question that keeps coming up is if DevOps is a sustainable career or if is DevOps dead?.
From my perspective, in the last 20 years, I’ve been a Computer Technician, Java developer, Java Senior developer, Network Administrator, Sysadmin, Software engineer, DevOps engineer, SRE, and probably some other things. But in all of those, I’ve done the same thing, I’ve implemented things to help businesses to be more profitable and to grow.
So the title really doesn’t matter, as long as you focus on adding value, you’re always going to have a job. So is DevOps dead? I don’t know. And I don’t really care. And sincerely, I don’t think you should either.

Getting into DevOps and its future, personal opinion.

DevOps is basically making the work of developers and operations automated more efficient and seamless, right? And since we have like a separate role as a DevOps engineer, basically what you do, the main responsibility is to take what developers have created and seamlessly in the most automated efficient, fast, secure, whatever way basically release it to the end users, right? So the whole process of taking that coded application, putting it on the end environment, and making it accessible to the end users in a secure way, in a highly performant available way, that’s the main responsibility of DevOps.

If you want to get into DevOps, you can use the software development entry as a first point, and then, even as a junior software developer, you can start transitioning into DevOps, because you would have enough foundational knowledge as a “prerequisite” to start learning the things that you need in DevOps.

DevOps is still relatively like, compared to other IT fields I would say relatively young, and there are a lot of things going on, there like a lot of dynamics, and you could see like a lot of different technologies that are being developed and invented for different use cases, or like problems that you have in the DevOps projects. And you also have like a lot of similar technologies developed in the same area, which is actually a sign of the fact that there is no one standardized solution for that. So I believe that the market trend, and the way that in the direction where DevOps is going to be developing, will be to standardize the processes more. To have like a few sets of tools that most of the projects, like 90% or maybe even more projects, will use. And all the rest of the technologies will just disappear because there has to be one winner in each category, so I think that’s going to be the trend versus now, where you have like ten or more different tools to choose from which are super similar for the same task, and then you have this thing, because none of them is super standardized, and the one that is mostly used, so you have to choose between them and evaluate them all the time.

But I think it’s going to standardize a lot more, and generally DevOps, because it’s becoming mainstream already, and we see that, that DevOps itself is going to become more clearly defined, and there will be like more clarity from the companies, what they expect from a DevOps engineer, where is the line between developer and DevOps engineer, where is the line between operations and DevOps.

I think that’s going to be in like, maybe four or five years, we’ll see that kind of standardization.

AWS IDP Short reference Architecture

Organizations must be agile and innovative to stay competitive in today’s software development era, which has led to changes in how applications are built, deployed, and managed.

This necessitates the transformation of static CI/CD setups into modern Internal Developer Platforms (IDPs) that provide developers with the tools needed to innovate and move quickly.

While every platform looks different, specific common patterns emerge. To help simplify things, I’ve consolidated the platform designs of dozens of setups into standard patterns based on real-world experiences, which have been proven to work effectively. By adopting these patterns, organizations can create IDPs that keep them ahead of the competition and deliver innovative applications faster.

This diagram provides an overview of one reference architecture for a dynamic IDP using AWS EKS, RDS, Backstage, Humanitec, GitHub Actions, Terraform, and several other technologies.

AWS IDP Architecture

Design principles.

01 Focus on the user. The most important customers of a developer platform
are developers. Developers need to be heavily involved in the design,
prioritization of features, and testing to ensure the platform is fit for purpose
and fully self-service. 

02 Run your platform team like a start-up. Establish a small central team that
owns the platform and is responsible for marketing it, ensuring it is easily consumable and fulfills developers’ needs.

03 Build golden paths vs cages. Developers should be free to choose their
abstraction level. While your IDP should provide a set of golden paths for developers to follow, it should never force their use.

04 Drive standardization by design. Enabling self-service means platform
engineers must define how to vend resources and configuration. This ensures
every resource is built securely, compliant, and well-architected.

05 Implement Dynamic Configuration Management. Dynamic Configuration Management significantly reduces config complexity and enforces standardization by continuously generating app and infrastructure configs with every single deployment. This allows you to enforce policies and standards with every git-push.

06 Let developers decide on their platform interface. The developer
platform should never break your developer’s workflow or force them to use a
specific interface. To support this, a code-based workflow by default works
best, with the option to use a UI, CLI, or API.

07 Keep code as the single source of truth. This ensures everyone is working
from the same version, reducing the risk of errors.

08 Assume a brownfield scenario. Use tools that have already been
productized and adopted by the organization (such as backlog management,
CI/CD toolchain, and container platform) and let the existing teams pursue
integration through plug-ins into the platform. Where applicable, organizations
should use open-source tooling and a cloud-native approach.