Whether you’re a fresh tech newbie or you’re an old-timer moving into DevOps, adding Linux to your skillset might seem rather intimidating. (Don’t worry, it does get easier!)
Once you’ve understood why it’s important to learn Linux for DevOps, and once you’ve learned about the basic components and concepts, you’ll be well on your way to being a pro. Linux is used everywhere in DevOps, so the better you understand it, the more you will feel comfortable taming those beastly cloud servers and containers. 🦁
Learning Linux for DevOps
Hey! We’re going to talk about learning Linux for use in DevOps and system administration, not for playing games, or home computing. (For that, there are many wonderful resources online, like Opensource.com’s Linux articles)
Why Linux for DevOps?
So why is it important to learn Linux if you’re a cloud or DevOps engineer?
Tools and platforms.
A lot of technologies start on Linux.
A lot of open source projects, especially DevOps tools, were designed to run on Linux from the start. Git was born out of the Linux kernel community, when it needed a new way to store code. Docker, which you’ve perhaps also heard of, was originally a combination of Linux utilities.
Nowadays, you can run Docker and Git on other platforms like Mac and Windows. But still, a lot of new technologies start on Linux, especially if they are related to software development or managing infrastructure. Ansible, a tool for managing servers, originally started on Linux too. Kubernetes is also a Linux project.
As a DevOps engineer, or a developer who’s leaning into Ops, it’s perhaps unlikely that you’ll be working exclusively on Linux, or exclusively on Windows or Mac. In practice, you’ll probably work with a mix of operating systems. But Linux will be one important piece in your puzzle.
Is it hard to learn Linux?
It’s not difficult to learn Linux basics, like logging on to a server, creating and editing files. This is good enough for everyday knowledge. But if you’re chasing a hardcore Linux job, then it can take years to become an expert.
So you might find it easier if you have a natural level of “curiosity” towards Linux. For example, you’ll often ask questions like:
What does [x] command do?
Where can I configure this program?
Why is this program not working?
Since Linux (or GNU/Linux) is made up of a whole heap of different programs and utilities, you often have to spend time finding the utility which does the job that you want, and then you need to find the focus to read and understand documentation. That’s where your natural curiosity will help.
But every time you learn something new, your knowledge will grow.
Now we’ve seen a bit about using Linux for DevOps, let’s look into the main components of Linux.
Components of Linux
Just like a car, Linux has a range of different optional features and luxury trims. But it always has an engine. And in Linux, the kernel is the engine.
- The Linux kernel
- The user space (or userland)
- The package manager
- The shell
- The desktop environment
With the exception of the kernel, all of these components can be swapped out and changed. This is why I think of Linux more like a kit car, which is assembled from different components, rather than a sports car which you might drive out of the showroom.
Let’s look at each of these sweet components in turn:
1. The Linux kernel
The kernel is the brain of a Linux operating system. It’s what makes all Linux systems… well, tick. It runs happily in the background, and you probably don’t even know it’s there.
The kernel manages your memory and devices, and provides the foundation for applications to run (in Linux these are called processes). Without the kernel, you probably wouldn’t be able to do anything.
Fun fact: Strictly speaking, the name “Linux” refers to the kernel. It was first created by a guy called Linus Torvalds. His name is embedded in the word “Linux”. (In fact, LINUX® is a registered trademark of Linus himself.)
2. User space (or userland)
This next space is the area where you will mostly live. User space, sometimes called userland, isn’t the name of a jolly Linux-themed amusement park, but the area of memory which the kernel sets aside for you to run your own programs.
Most of the programs you will ever run, the dreams you will ever have, and the “stuff” that you will ever do, will happen in user space. Command line utilities, web browsers and database servers all live here. These programs might be provided by the GNU Operating System project, or they might be provided by other communities or companies.
3. The package manager
When you want to install programs onto your Linux operating system, you generally use a package manager. The package manager can search online for software to download, download the right files, and then install them for you.
There are a few different competing package managers, which have snappy names like
apt. Which package manager you use, depends on which Linux distribution you’re running. (More on distributions further below.)
This dependency from one program to other programs, is both one of the amazing things about Linux (and also sometimes one of the most frustrating things!)
4. The shell
The shell is the part of Linux where you will run commands. It’s like your driving seat. This is the place where you issue instructions and run scripts.
When you log on to Linux, you start a shell or terminal. You can also start a shell in a Linux Docker container.
There are a few different shells in Linux, the most common one being the infamous bash. There’s also ksh, zsh and the classic sh (“Bourne shell”). Each of these shells has different features and time-saving stuff, so they’re all very slightly different from each other.
5. The desktop environment / window manager
A desktop environment lets you run graphical programs. Yes, if you want to run Minesweeper, Solitaire or Candy Crush then you’ll need a desktop environment.
But, Linux doesn’t need a desktop environment to run. In fact, most servers don’t have a desktop environment. This is important to understand if you’re learning Linux for DevOps. You’re more likely to be changing files and running programs using a terminal, not a desktop.
Omitting the desktop environment tends to save resources and improve speed (well, in theory).
No two Linux distributions are alike, and you’ll encounter administration challenges, and headaches for days. But once you’ve got a good grasp of the basics, you’ll be well on your way to tackling whatever tasks lay ahead of you.
Distributions are your choice of Linux.
There isn’t one single “Linux operating system”.
There isn’t one single “Linux operating system”.
Instead, Linux is more like an ecosystem, which means there is a lot of composability and choice.
Composability… means that Linux programs are designed to be composed together. Like taking many tiny Lego bricks to build something big.
Choice… means the ability for you to choose different programs to build your own Linux environment. Like building a custom car from your own choice of parts.
Having said that, few people really build a Linux system from scratch, so there are some well-known variations of Linux, which are called distributions, or distros. Each of these distributions includes the kernel, a package manager, a set of userland programs to perform common tasks, and (sometimes) a desktop environment.
(Now do you get why we introduced these concepts first?)
Does it matter which Linux distribution you use?
Linux distributions vary, in terms of what comes included “in the box”. For example:
- Some distributions are easier to install than others.
- Some distributions are designed for playing games.
- Some are designed for specific purposes, like security testing.
- Some follow a specific ideology, like only free software.
- And some are specialised to run on certain types of hardware, like the Raspberry Pi.
And, on top of this, each Linux distribution has its own loyal band of followers.
Many Linux distributions share the same core set of packages, so your Linux knowledge is quite transferrable to other distros.
So the whole concept of Linux can seem pretty tribal to the beginner. And choosing a Linux distribution feel be a bit intimidating.
However, most Linux distributions are very similar. They usually include a core set of packages (from GNU), so if you learn one distribution, you should be able to transfer a lot of that knowledge to another distro.
Learn the Linux distribution that you plan to use day-to-day. By spending time in the same distribution, you’ll get familiar with its userland programs, its package manager, and whatnot.
Linux in the enterprise world
You can run Linux without support, but if something goes wrong, you’ll either need to fix it yourself, or wait for someone else to fix it.
Companies often choose a Linux with commercial support, especially if they’re running critical software.
So although there are many different distributions of Linux, there are only a few key distributions to know about in the “enterprise”/”DevOps” world. So let’s take a look at them.
Linux distributions for DevOps
Big companies often stick with well-known, established distributions. This can be for a few reasons, but most often it’s because they want support, and because the applications they want to run are certified to run only on these distros.
Here are the most common distributions that you might use if you’re working in DevOps, in a corporate environment.
Red Hat Enterprise Linux, CentOS & Fedora (and Amazon Linux)
These Linux distributions are so closely related, they might as well be sharing the same bed. 🤨 They share a lot of the same characteristics and programs, so we’ve lumped them together under one heading.
CentOS (now CentOS Stream) is a more “stable” distribution designed for servers, with fewer packages available for it, and with less frequent releases. Many companies run CentOS because they want a slow, stable Linux distribution, but without the cost.
Red Hat Enterprise Linux (often called RHEL, and pronounced “rel”), is even more stable and slow-moving, and closely follows CentOS. It’s mostly used in large companies, such as banks. It’s commercial (💰💰💰), but you can get a free developer subscription from Red Hat if you want to try it out yourself.
Amazon Linux is also in this list. If you spin up a basic EC2 machine in AWS, you’ll probably be using Amazon Linux. It’s loosely similar to the other distributions above.
Fedora is a Linux distribution for home users and hobbyists. It’s less likely to be used in DevOps or to run a server. This is because it has regular releases, tends to change quite often, and is geared more towards personal desktop use.
Ubuntu and Debian are two closely related distributions.
Ubuntu is massively popular, and for good reason. It’s easy to install and use, which is why it’s been adopted by everybody from gamers to developers.
You will also find it used in the enterprise, as some companies get enterprise support for it.
Alpine Linux isn’t about typing commands on lush Alpine meadows, whilst singing The Sound of Music (sadly).
Alpine is a Linux distribution designed primarily for small size. It doesn’t include a bunch of stuff you might get in other Linux distributions. And it’s gaining a lot of support because it’s stripped-back nature, which makes it ideal for running applications in containers.
If you want to install Linux in your home, and you’re trying to choose a distribution, then check out https://distrochooser.de/en/. You just enter your preferences and things you want to do with Linux, and it will help you choose a Linux distribution. Ace.
So assuming that you want to get started, what are some top tips for learning Linux for DevOps?
3 tips for learning Linux for DevOps
1. Get a Linux server of your own
You can get started with Linux by creating a Linux virtual machine on your own PC, using a program like VirtualBox. A virtual machine is a safe environment. In a VM, you can play around and learn, without being too concerned, because you won’t break anything.
Once you’ve learned some of the basics, you might then choose to dual-boot to Linux. This means that you install Linux as a secondary operating system on your PC.
2. Get command line experience
If you’re learning Linux for DevOps, you should force yourself to use the command line. So, ideally, install a Linux distribution without a desktop environment.
If you don’t install a desktop environment, you’ll only have the shell/terminal as your friend. But you will make the quickest progress this way.
When you’re learning the command line, also make time to learn a text editor like
vim. Vim is the text editor that comes with most distributions of Linux, with a quirky set of keyboard commands that take time to learn but will help you get things done quicker.
3. Know the emergency number, man
On Linux Flight LX101, your emergency exit is
man is short for “manual” and is your friend. Man holds the manual for almost everything on your Linux system. It tells you how to run commands, how to configure things, and is an absolute goldmine of info.
The only problem is, you need to know how to read it. Spend time learning how to use
man first, and it will pay dividends for you in the future.
You can also find Linux help on forums and Q&A sites, like Unix & Linux Stack Exchange.
4. Take a course and/or an exam
If you want to go step-by-step through learning Linux and the command line, then take a course and an exam.
Try to find a course for system administrators. This will give you a good grounding in Linux commands, managing a server, installing packages, and so on.
Here are some ideas for Linux training:
Training for the Red Hat Certified System Administrator (RHCSA) certification will give you the knowledge you need to be confident with Red Hat Enterprise Linux.
The Linux Foundation offers Linux system administration training and certification. The Linux Foundation Certified System Administrator (LFCS) is a well-recognised certification.
Hello, Linux expert!
It might take a little while to get comfortable with Linux, especially if you’ve never used a command line before. But with a little perseverance, you’ll be
cding in no time, and Linuxing like the absolute boss you were born to be.
(If you want to find out what
cd do, check
man for the manpages!)
Got any thoughts on what you've just read? Sign in with your GitHub account and leave a comment.
(All comments get added as Issues in our GitHub repo here. We don't use your GitHub account to do anything else.)