DEV Community: theelvace.eth

Revolutionizing Application Deployment and Scalability Using Docker

theelvace.eth — Tue, 04 Jul 2023 08:04:35 +0000

Table of content:

Introduction
Understanding Docker: An overview
Docker Containers
Docker Images: Building blocks of application deployment
Streamlining development with Docker Compose
Orchestrating containers with Docker Swarm
Scaling applications with Docker Swarm mode
Achieving high availability with Docker services
Monitoring and managing Docker containers
Best practices for secure and efficient Docker Deployment
Conclusion

Introduction

The digital landscape is an ever-evolving one. As a result, there is a need for the efficient deployment and scalability of applications. This is where Docker, a containerization software has proven to be a game-changer. Docker is revolutionizing how software is built, shipped, and run by encapsulating applications and their dependencies into lightweight containers that unleash their flexibility, portability, and scalability.

Prerequisite:

To get the most out of this guide, it is essential that you have a basic understanding of the concepts guiding application development and deployment. Being familiar with topics like software development life cycle, cloud computing, and virtualization will provide you with a solid foundation for understanding the power of Docker in deploying applications in a streamlined way and achieving unparalleled scalability.

If you are unfamiliar with these technologies, we recommend that you take some time to familiarize yourself with them before proceeding as they will provide you with the prerequisite knowledge you need to get a grasp of the nuances and benefits of Docker's style to application deployment and scalability.

Understanding Docker: An overview

Managing an application's dependencies across various cloud environments has proven to be a common problem for DevOps teams. DevOps teams, as part of their regular tasks, make sure to keep the application stable and operational while development teams have their strength in releasing new updates and product features. Now, while there is a need to improve applications so they can serve us better, regular "new update" releases can compromise the stability of the application. Even more when deployed codes introduce bugs that are dependent on the application's environment.

This is a big issue and in an effort to avoid this inefficiency, companies are increasingly adopting the model of a containerized framework that allows for the designing of a stable framework. A framework that does not have issues like security vulnerabilities, operational failures, and complexities added to it.

Containerization in simple terms is the process of building and packaging an application's code with all of the dependencies, configuration files, and libraries that the application needs, into an isolated environment (sometimes called a Sandbox), where they can operate efficiently as an independently executable unit.

Containers are popular for their usability issues but they have gained an increased level of prominence in recent times since Docker entered the fray.

What is Docker

Docker is a free-to-download open-source containerization platform that allows developers to build, ship, run, and package applications with ease using containers. Docker technology is packaged as containers (standardized units), with elements like libraries, system tools, runtime, etc that are needed for the software to function properly. The operations provided by the platform can be carried out using the Command Line Interface (CLI) it comes with.

If you are familiar with software environments, you could say Virtual Machines (VMs) are another way with which you can create isolated environments but Docker, unlike VMs, offers perks like faster execution of applications, interoperability, and build and test efficiency.

Installing Docker

You can Install Docker on a Linux-based system with the following steps:

sudo apt update

to update the package index

Install required packages to allow apt to use a repository over HTTPS with:

sudo apt install apt-transport-https ca-certificates curl software-properties-common

Add the official Docker GPG key using:

curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg

Add Docker repository to APT sources with:

echo "deb [arch=amd64 signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

Update the package index again:

sudo apt update

Now install Docker Engine:

sudo apt install docker-ce docker-ce-cli containerd.io

Verify that Docker is installed and running with:

sudo systemctl status docker

If the above command's output shows that Docker is active and running, then you have successfully installed Docker on your system.

Note that these commands and instructions are specific to Ubuntu-based systems. Other Linux distributions may have varying commands and packages. Refer to the official Docker documentation for instructions on how to install Docker for the specific Linux distribution you use.

Docker Containers

Containers are live instances of a Docker image on which the application runs. You can create, start, stop, or delete a container by using the Docker CLI or API. A container by default is isolated from other containers and its host machine, but you can control how isolated a container's network and other subsystems are from other containers or from the host machine.

A container can also be connected to one or more networks, storage attached to it, and even create a new image based on the container's current state.

You can use Docker Compose, an open-source tool to define and deploy multi-container Docker applications. You can use a YAML file to configure the application's services. Docker Compose works in all environments and it has commands that help you manage the entire lifecycle of your application.

Installing and Using Docker Compose

Follow the steps below to install and use Docker Compose:

Install Docker Compose:

sudo curl -L "https://github.com/docker/compose/releases/latest/download/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose

Add executable permissions to the binary:

sudo chmod +x /usr/local/bin/docker-compose

Check the version to verify the installation:

docker-compose --version

Next, create a Docker Compose file in your project directory docker-compose.yml. The file defines the services, networks, and volumes for your application.
Define your services using the appropriate syntax inside the Docker Compose file.

Example of a simple Docker Compose file:

version: '3'
   services:
     web:
       build: .
       ports:
         - '8000:8000'
     db:
       image: postgres
       environment:
         POSTGRES_PASSWORD: example

The example above defines two services: web and db. The web service builds an image from the current directory and maps port 8000 on the host to port 8000 in the container. The db service uses the postgres image and sets the POSTGRES_PASSWORD environment variable.

Start the services defined in the Docker Compose file from your project directory:

docker-compose up

This command starts the containers and displays the logs in the terminal.

You can use the -d flag to run the containers in the background:

docker-compose up -d

You can stop and remove the containers using:

docker-compose down

This stops and removes the containers defined in the Docker Compose file.

Note: To do all of these, it is assumed that you already have Docker installed.

Docker Images: Building blocks of application deployment

Docker Images help you create a Docker container. Default images show all the top-level images, their repository and tags, and their sizes. Images essentially define the application's dependencies and the processes that run when the application launches.

Docker Images has intermediate layers that are not shown by default and they increase reusability, decrease disk usage, and speed up Docker build as each step is cached. Images are building blocks of application deployment and you can get them from DockerHub or you can create your own images by adding specific instructions to a file called Dockerfile.

Setting up Docker Image

After creating the Docker file, open it in a text editor and define the instructions to build your Docker image. See an example of a Dockerfile for a basic Python application:

# Use a base image with Python pre-installed
   FROM python:3.9

   # Set the working directory in the container
   WORKDIR /app

   # Copy the requirements file and install dependencies
   COPY requirements.txt .
   RUN pip install --no-cache-dir -r requirements.txt

   # Copy the application code into the container
   COPY . .

   # Specify the command to run when the container starts
   CMD ["python", "app.py"]

The example above has the python:3.9 base image pre-installed. The working directory in the container is set to /app, and it copies the requirements.txt file, installs dependencies, and then copies the rest of the application code. In the last line, it specifies the command to run when the container starts.
You can customize the Dockerfile according to the requirements of your application. For advanced options and instructions, refer to the Docker documentation.
Next, save the Dockerfile in your project directory.
Build the Docker Image with the docker build command by opening a terminal or command prompt and navigating to your project directory:

docker build -t your-image-name .

Replace your-image-name with your desired Docker Image name.

The build context is defined as the current directory by the . at the end.

Docker will then execute the instructions in the Dockerfile and build the image. This process may take some time depending on the size of the project and the instructions defined in the Dockerfile.
You can verify that the image was created by running:
docker images

This command will list all the Docker images on your system, and you should see your newly created image listed.

Your Docker image is now set up and ready to use.

Note: You can run containers based on this image by using the docker run command and specifying the image name.

Streamlining development with Docker Compose

With a single YAML file, using Docker Compose, a developer can describe their application's services, volumes, and networks in a YAML file. This makes it easy for the configuration and reproduction of development environments across different machines. With the use of Docker Compose, it is easier for the developer to spin up containers that are interconnected, testing, debugging, and iterating their applications with ease.

The process of managing dependencies is simplified by Docker Compose, and this ensures that the necessary services are available and properly connected. This tool streamlines development by providing an easy and efficient way to define, manage, and orchestrate multi-container applications. This approach accelerates development cycles.

Orchestrating containers with Docker Swarm

You can create and deploy a cluster of Docker nodes with the aid of Docker Swarm, an orchestration tool that works with Docker applications. With this tool, containers are launched with the use of services. Services are containers of the same image that enables the scaling of applications. To deploy a service in Docker Swarm, the user must have at least one node deployed.

A node in a Docker Swarm is a Docker daemon and they (Docker daemons) interact through the use of the Docker API.

Scaling applications with Docker Swarm mode

Scaling applications using Docker Swarm and achieving a high level of availability and scalability involves proper deployment and management of a cluster of Docker nodes. Docker nodes are essentially a swarm created in swarm mode. These nodes in a swarm act as a single entity.

As a developer, you need to define a desired number of replicas in the Docker Compose file or use the Docker command line to scale an application. As you scale up, additional replicas are created and spread across the nodes. Scaling down removes the excess replicas. If there is an increase in traffic, the swarm mode load balances the requests among the service replicas automatically. This way, applications adjust their capacity to efficiently meet demand and maintain high-performance standards.

Setting up Docker Swarm

You can follow these steps to set up Docker Swarm:

Initialize Docker Swarm on the manager node (your machine) with:

docker swarm init

If successful, the output will include a command to join worker nodes to the swarm. You need to copy this command because you will need it to join worker nodes later.

To add worker nodes to the swarm, run the command that you copied from the previous step on each worker node:

docker swarm join --token <TOKEN> <MANAGER_IP>:<MANAGER_PORT>

You should replace <TOKEN> with the token value from the command output and <MANAGER_IP> and <MANAGER_PORT> with the IP address and port of the manager node.

Next, you can check the status of the swarm and view the nodes:

docker node ls

This lists all the nodes in the swarm, including manager, and worker nodes included.

Create a Docker Compose file (e.g., docker-compose.yml) to deploy a service on the swarm that defines your desired services, networks, and volumes.
Deploy the stack defined in the Docker Compose file using the following command:

docker stack deploy -c docker-compose.yml <STACK_NAME>

You should replace <STACK_NAME> with a name of your choice for the stack.

After these, Docker Swarm will create the necessary services, networks, and volumes that are specified in the Docker Compose file. Docker Swarm will also distribute them across the available nodes in the swarm.

To view the running services in the swarm, use the command:

docker service ls

For advanced usage and added features of Docker Swarm, refer to the Docker documentation.

Achieving high availability with Docker services

Implementing strategies to ensure that an application that runs in a Docker container is still accessible even with disruptions is important in achieving a high level of availability with Docker services. Typically, this is achieved by deploying multiple instances of the application across a cluster of Docker nodes, and Kubernetes or Docker Swarm can then be used to distribute containers across the cluster.

To ensure the even distribution of traffic among the containers, load balancing techniques are employed. Doing this prevents any instance from being overwhelmed. Auto-recovery mechanisms and regular health checks can be used to detect and recover container failures. Doing these and leveraging scalability, ensures that high availability is achieved and that Docker services are continuously available thereby reducing downtime for applications.

Monitoring and managing Docker containers

Docker Containers provide developers with so many benefits. Benefits like the ability to test and deploy an application with ease, cost-effectiveness, and mobility are some of the perks of containerization. It is important to manage Docker containers because many services depend on them.

Command line interfaces are more common than Graphical User Interfaces (GUIs), which play perfectly in managing Docker containers. A GUI generally has changes done to it regularly and the user experience can prove difficult because options and how they work are changed. In contrast, a CLI doesn't get updated a lot and this makes it easy to get used to.

There's also the issue of GUI having bug problems which affect the operation of managing Docker. The CLI is largely bug-free and stable. All these make managing Docker containers using CLI tools convenient and safe. These are some commands that you can use to monitor Docker containers in real time:

docker attach: Helps you attach to a running container and view outputs
docker events: Use this to view real-time events from the Docker daemon. Events like when a container is created or destroyed
docker top: This helps you view the running processes of a container
docker logs: To view the logs of a running container

Examples of some Docker CLI monitoring tools you can try are Dockly, Dry, Poco, Dive, etc.

Best practices for secure and efficient Docker Deployment

An efficient Docker deployment involves several best practices that ensure the protection of containerized applications. Below are some of these practices:
Use base images from trusted and reliable sources and keep them updated with regular security patches
Employ network segmentation and container network security measures to help protect the application against network-induced attacks.
Implement strong access controls like user namespaces, and restrict the container's capabilities to enhance isolation and reduce potential vulnerabilities.
Use container orchestration platforms like Kubernetes to enable efficient management of containerized applications, load balancing, and automatic scaling.
Use security tools to scan containers and their dependencies regularly for known vulnerabilities.
Monitor and log container activities and implement centralized logging and Security Information and Event Management (SIEM) solutions. This allows for effective security incident detection and response.

Conclusion

Docker has become a game-changer in application deployment and scalability. This technology leverages lightweight containers and flexible orchestration tools to empower businesses to streamline their development processes and scale applications to meet the ever-growing demands of the digital landscape. As Docker continues to evolve, embracing it is not just a choice, it is an essential step toward reaching a new level of efficient application deployment and scalability.

What You Need to Know About Run Levels in Linux

theelvace.eth — Mon, 24 Apr 2023 20:59:41 +0000

Graphical user interface (GUI) and command-line interface (CLI). Oh, snap! I realize I’ve just blurted out those terms without context, let me add context. The GUI and CLI are the two options a Linux operating system (OS) boots to when turned on. When the system finishes booting up, the applications it executes are determined by Run levels. Run levels also determine the state of the system after booting.

In essence, run levels in Linux can be considered as the different modes the OS runs in. These modes/run levels have their list of processes or the services they provide and these are either turned on or off. As you continue to work with your computer, and depending on the kind of services the OS is accessing, the run level may change.

For instance, if you are running your Linux machine with a GUI, the run level for this is different from when you are running the CLI on your system. The reason for this is simple. The GUI will need access to services that the command line does not need.
_

In this article, we will talk about run levels in Linux, the different types of run levels, changing run levels in a system, list services that are enabled at a run level, and some Init scripts.

Table of Contents

What is Run Level?
Linux System Boot Process
Types of Run Levels
Changing Run Levels
Services That Are Enabled at a Run Level
init scripts
Examples of Run Level Commands
Security Issues That Affect Run Levels in Linux
Conclusion
Resources

What is Run Level?

A run level is an operating state of init on a Unix or Linux-based operating system. It determines what system services are operating and which programs can be executed after the OS boots up. In essence, the state of the machine after boot is defined by the run level.

System administrators use run levels to define system-related issues like which subsystems are working if the network is operational if a command/file/program is running etc. The run level command

/sbin/runlevel

can be used to find out the current or previous run level of the OS. These run levels are usually identified by numbers (0–6). Each of these levels controls a system configuration different from the other levels and they allow access to the combination of different processes.

To view the current run level for a system, you can use the command:

$ runlevel

The command below can also be used:

$ who -r

Linux System Boot Process

When a Linux system boots up, the first thing that happens is that the init process starts. To execute the start scripts that are appropriate for the default run level, the init first determines the system’s default run level. It is this process that is responsible for the initialization of the hardware, bringing up the network, and starting the GUI.

Types of Run Levels

There are seven run levels in Linux and they are numbered from zero to six. According to the operating system or Linux distribution, these run levels may be used differently. As a result, it is not very easy to come up with a clearly defined list of the run levels and what they do. You should check the specific distribution that you use, and how the run levels work on it.

However, the standard LINUX kernel supports the seven different run levels listed below:

Run Level 0 — In this run level, the system can safely be shut down
Run Level 1 — This is a single-user mode and it is used for maintenance or administrative activities. This mode can also be referred to as run level S(S represents single-user).
Run Level 2 — This is a multi-user mode and it has no Network File System (NFS).
Run Level 3 — This is a multi-user mode under the command line interface. It is the run level you use if your system doesn’t boot into a graphical user interface.
Run Level 4 — This run level is user-definable. What this means is that the user can customize the level to fit their purposes.
Run Level 5 — This run level works the same as run level 3, but it also starts a display manager. This is the standard run level for most Linux-based systems that boot up into a GUI.
Run Level 6 — This run level reboots the system.

It is important to note from the above listed that each run level has a different purpose.

Run levels 0,1 and 6 are the same.
Depending on the Linux distribution being used, Run levels 2–5 are different
When the system is booted, only one level executes
Finally, run levels are executed in a sequence. This means that either levels 2 or 3 or 4 are executed, and not 2 then 3 then 4.

Changing Run Levels

Using the init or telinit command, we can alter the run level. The telinit command can be used to invoke the init program, which is used to change the run level.

For instance, to reboot a system, you can use the:

$ init 6

$ telinit 6

To change the run level, we first have to get the current run level by using the systemctl command:

$ systemctl get-default

Graphical.target represents run level 5. Other targets include

poweroff.target (run level 0), rescue.target (run level 1), multi-user.target (run level 3), and *reboot.target (run level 6).

Now we can change the run level from the current level it is at to run level 3. This run level supports multi-user and on it, we can operate in the CLI with networking enabled.

$ sudo systemctl isolate multi-user.target

We are directed to a login screen on a command-line interface after entering the password.

We can confirm the run level by using the command:

$ who -r

To go back to the graphical interface, we can use the command:

$ sudo systemctl isolate graphical.target

Note: It is important to note that the changing of run levels is a task for the super user. This is why for the successful execution of the changing run levels process above, it is important to be logged in as the super user. Or you can use the sudo command.

Services That Are Enabled at a Run Level

Until recently, to list the services that would be enabled at different run levels, “chkconfig — — list” was the command used. However, if your OS is up to date, using that command may give you an error or push you over to systemd.

Now if we want to see what services will be enabled when we boot our system into the run level 5 (graphical mode), we can use this command:

$ systemctl list-dependencies graphical.target

We can replace “graphical.target” with the name of a target service we want to see to see the services that run by default on other run levels.

init scripts

init is the program that is responsible for launching other processes during the boot-up of a system. Linux system’s default state is configured in scripts of config files and these are located in the /etc/init.d/ directory:

$ ls /etc/init.d/

Run levels are found in the /etc/ directory, and each run level has its directory here:

$ ls /etc/ | grep rc

In each subdirectory, configuration files for a run level are kept. For example, to list all the configuration scripts under run level 0, we can use

$ ls /etc/rc0.d/

Examples of Run Level Commands

To see the current run level use the:

$ runlevel

To suppress the output:

$ runlevel -q
$ runlevel - quiet

To run in verbose mode:

$ runlevel -v
$ runlevel - verbose

To get the version info:

$ runlevel - version

To get help:

$ runlevel - help

To check the runlevel manual:

$ man runlevel

Security Issues That Affect Run Levels in Linux

The main point of run levels in Linux is to give the system administrator granular control over the system. Such control improves security because the administrator is then sure that no other services are running without permission. A very important practice when using run levels is to only use the run level you need. This means that there is no point in starting the graphical interface (run level 5) when you only want to use the terminal. Doing this — having different run levels on — introduces multiple services, some of which you may forget to secure because they run in the background.

Conclusion

It is important to understand run levels and how they work. Knowledge of this is useful especially when accessing the system, fixing a damaged config file, or in the case of a forgotten password. In any of these situations, we will boot into a single-user mode. And as mentioned earlier in the article, run level configurations vary across the different Linux distributions.

Resources

You may find the following resources helpful:

The Basics of Package Management in Linux

theelvace.eth — Mon, 24 Apr 2023 19:48:06 +0000

In our world today, technologies move at a fast pace. Constant development and deployment provide the end-users with a plethora of options. As a result of these regular launchings, the possibilities of errors occurring are more pronounced. Errors when left unchecked lead to bad code which in turn affects the product’s quality.

This is why it is important to carry out necessary updates and automate real-time checks on the software. Most importantly, these should be done without affecting the performance of the application. DevOps and Cloud Infrastructure Engineers have these unenviable tasks, and where they are not present, the companies use DevOps practices to ensure the release of quality software, while building quality collaboration between their Developers and Operations teams.

To be a well-grounded DevOps Engineer or implement DevOps practices efficiently, it is important to have solid knowledge and experience in the basics. One of these basics is Linux and the management of packages in it.

This article will show you what package management in Linux is, how you can get started in it, the different package management systems and their benefits, and some core concepts and commands to help you install and work around these package managers.

The most common tasks a sysadmin has to take care of are installing, patching, and removing software packages on Linux machines. This is because, on Linux, the software is generally built as packages which are then distributed through repositories (repos) before entering the management phase on the end-user’s system through package managers.

Package Management

The method of using specific repositories to install, update, remove, and track software updates in the Linux system is known as Package Management. Every Linux system contains thousands of packages, of which many are required dependencies for other packages.

A package manager is a software in a Linux system that provides a consistent and automated process of installing, upgrading, configuring, and removing packages from the operating system.

Operating systems (OS) depend on software applications to carry out tasks that solve problems for the user. When software and operating systems were still early and weren’t that popular, applications were developed and tested for bugs before they were released. This was done to provide a good user experience. Not any longer. Now, applications are released to apply bug fixes in newer versions. These newer versions are accessed with the use of updaters or by the user obtaining an upgraded release of the software.

Linux however has adopted a timely software management practice where they create packaging formats, unique tools for installation, and software packages. To achieve these, Linux distributions (distros) use different package management tools. In the rest of this article, we will talk about package installation tools like Tarball and package management tools like DEB and RPM, and YUM.

Tarball

In adding software to early Linux systems, the user was required to download the source code of the software and compile it in binary files, before adding them to the system. The software is made available by users in a compiled form that is known as the tarball (Tar). A tarball typically contains multiple files ranging from configuration files to documentation, to executables, and libraries. All of these files are compressed into a single file for ease of storage and distribution.

Short for “tape archive,” Tar is especially useful for testing and development of software and it supports most Linux distributions like Ubuntu, CentOS, and Amazon Linux 2. While the creation of tarball may seem easy, the process of installing it isn’t as easy. For example, because tarball package installation spreads the files connected to the software being installed across the system, it’s not an easy task locating the package documentation and configuration files even if the user knows the commands.

This makes it difficult to locate files to uninstall software. Tracking bugs and getting newer versions of software also becomes difficult because of the absence of Metadata in tarballs which confuses the version details after installation. To solve these problems, software packaging in Linux distributions grew into two formats:

Debian-based Linux distributions
RPM Packaging

Debian-based Packaging (DEB)

This is the software package used by Debian Linux distributions. All relevant files with metadata in a .ar archive format are included in the .deb files. The metadata here contains relevant details of the software like the version, licenses, description, dependencies, etc. Debian distributions are popular for offering both graphical interfaces and terminal-based tools for managing .deb files.

Some of these tools include:

dpkg

This allows the user to set up, remove, manipulate, and upgrade software easily. The dpkg downloads DEB package content to the system and sends notifications about the essential dependencies. You can install a .deb file using dpkg with the command below.

sudo dpkg -i <package name>.deb

Apt

This is an Ubuntu advanced package manager that uses an apt-get command to search and manage package installation. You can install a package from the repository using the apt-get command.

sudo apt-get install -s <package name>

Aptitude

This is a package management tool that provides a text-based interface to run in the terminal. Because Aptitude doesn’t come pre-installed in all Linux distros, you will have to install it with the following command:

sudo apt-get install aptitude

Once Aptitude is installed, to install a package, issue the following command:

aptitude install <package name>

Ubuntu Software Centre

This is an intuitive graphical user interface that users who are new to Linux can use in searching and installing packages.

RPM Packaging

Originally called Red Hat Package Manager, the RPM Package Manager is an open-source program for installing, uninstalling, and managing software packages in Linux. It is used in CentOS, Red Hat, Fedora, OpenSUSE, OpenMandriva, and RHEL-based Linux distributions. The RPM Package Manager combines binaries and available files that are required via upstream software providers to create an RPM package. With the aid of signatures, users can verify the validity of packages before they are added to a repository. With this done, users can access the verified packages from the repositories that are placed inside the CDs or directories through FTP/NFS servers.

How to use RPM

To use RPM commands you first need to gain sudo permission and you’ll probably need to have a package you want to install already.

Install RPM Package

To install a file using RPM, you can execute the following command:

$ rpm -i [package_file_name].rpm

Uninstall RPM Package

To uninstall a package, you can use the package name instead of the full RPM file name. You can also add more package names. This will help you remove multiple packages in one command.

$ rpm -e [package_name] [another package_name…]

Upgrade

$ rpm -u [package_file_name].rpm

Verify RPM Package

Use the command below to verify an installed RPM package.

$ rpm -Vp sqlbuddy-1.3.3–1.noarch.rpm

Query RPM Package Information (Before Installing)

To see a package’s information before you install it, use

$ rpm -qip [package_name]

Query Package Information (After Installing)

To see the package information after installing, you can use

$ rpm -qi [package_name]

List Documentation of Installed RPM Package

To check the available documentation of an installed RPM package use the command

$ rpm -qdf /usr/bin/[package_name]

There have been some problems with the RPM package. A major one is that it fails in the absence of dependencies. While the DEB-based software packaging could resolve this dependency problem, following the increasing popularity of RPM packages, YUM facilities are resolving the issue better.

Yellowdog Updater Modified (YUM)

YUM serves as the primary package management tool for installing, updating, and managing software packages in Red Hat Enterprise Linux. YUM is used to manage packages in CentOS/RHEL 7, Fedora 21, and earlier versions of these distributions. It carries out dependency resolution when installing, updating, and removing software packages.

YUM was introduced initially to manage the dependencies of RPM packages. It considers each RPM package as part of a large software repository. YUM provides an interface that is easy to use on top of the functions that are available in the RPM Package Manager. YUM’s main configuration file is at /etc/yum.conf, and the repos are at /etc/yum.repos.d.

There are a lot of commands and options available to use with YUM. Below are a few of them:

yum install — To install specified packages
update — To update each package
remove — This removes specified packages
search — To search for keywords
repolist — This lists repositories

Conclusion

In this article, you’ve learned what package management is and some package managers there are. Package management is a constant for every system and a task that needs to be carried out. Managers like RPM and YUM provide seamless ways of installing, upgrading, removing, and tracking software packages on RHEL systems.

Resources

You may find the following resources helpful: