This post was originally published on Red Hat Developer. To read the original post, visit Build your own RPM package with a sample Go program.
A deployment usually involves multiple steps that can be tricky. These days, we have a wide variety of tools to help us create reproducible deployments. In this article, I will show you how easy it is to build a basic RPM package.
We have had package managers for a while. RPM and YUM simplify installing, updating, or removing a piece of software. However, many companies use package managers only to install software from the operating system vendor and don’t use them for deployments. Creating a package can be daunting at first, but usually, it’s a rewarding exercise that can simplify your pipeline. As a test case, I will show you how to package a simple program written in Go.
Creating the package
Many sites rely on configuration managers for deployment. For instance, a typical Ansible playbook might be:
tasks:
- name: 'Copy the artifact'
copy:
src: 'my_app'
dest: '/usr/bin/my_app'
- name: 'Copy configuration files'
template:
src: config.json
dest: /etc/my_app/config.json
Of course, a real-life playbook will include more steps, like checking the previous installation or handling services. But why not use something like this?
tasks:
- name: 'Install my_app'
yum:
name: 'my_app'
Now, let’s see our Go application that serves up a webpage. Here's the main.go file:
package main
import (
"encoding/json"
"flag"
"fmt"
"io/ioutil"
"log"
"net/http"
)
type config struct {
Text string `json:"string"`
}
func main() {
var filename = flag.String("config", "config.json", "")
flag.Parse()
data, err := ioutil.ReadFile(*filename)
if err != nil {
log.Fatalln(err)
}
var config config
err = json.Unmarshal(data, &config)
if err != nil {
log.Fatalln(err)
}
http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
fmt.Fprintf(w, config.Text)
})
log.Fatal(http.ListenAndServe(":8081", nil))
}
And our config.json:
{
"string": "Hello world :)"
}
If we run this program, we should see a web page with the config.json text in port 8081. It's far from production-ready, but it will serve as an example.
Adding services
What about a service? Adding services is an excellent way to unify the management of an application, so let’s create our my_app.service:
[Unit]
Description=My App
[Service]
Type=simple
ExecStart=/usr/bin/my_app -config /etc/my_app/config.json
[Install]
WantedBy=multi-user.target
Every time we want to deploy our application, we need to:
- Compile the project.
- Copy it to
/usr/bin/my_app. - Copy the
config.jsonfile to/etc/my_app/config.json. - Copy
my_app.serviceto/etc/systemd/system/. - Start the service.
Creating the spec file
Like Ansible, an RPM package needs a definition file where we specify the installation steps, the dependencies, and other things that we might need to install our application on a server:
$ sudo dnf install git
$ sudo dnf module install go-toolset
$ sudo dnf groupinstall "RPM Development Tools"
With all of this installed, we are ready to create the package definition file, also known as the spec file:
$ rpmdev-newspec my_app.spec
A spec file can be tricky, but we will keep this simple to appreciate the power of the tool:
Name: my_app
Version: 1.0
Release: 1%{?dist}
Summary: A simple web app
License: GPLv3
Source0: %{name}-%{version}.tar.gz
BuildRequires: golang
BuildRequires: systemd-rpm-macros
Provides: %{name} = %{version}
%description
A simple web app
%global debug_package %{nil}
%prep
%autosetup
%build
go build -v -o %{name}
%install
install -Dpm 0755 %{name} %{buildroot}%{_bindir}/%{name}
install -Dpm 0755 config.json %{buildroot}%{_sysconfdir}/%{name}/config.json
install -Dpm 644 %{name}.service %{buildroot}%{_unitdir}/%{name}.service
%check
# go test should be here... :)
%post
%systemd_post %{name}.service
%preun
%systemd_preun %{name}.service
%files
%dir %{_sysconfdir}/%{name}
%{_bindir}/%{name}
%{_unitdir}/%{name}.service
%config(noreplace) %{_sysconfdir}/%{name}/config.json
%changelog
* Wed May 19 2021 John Doe - 1.0-1
- First release%changelog
A few notes:
- The
Source0entry can be the source code repository, something like this:https://github.com/user/my_app/archive/v%version.tar.gz. - If you use a URL in
Source0, you can issuespectool -g my_app.specto download your source code. - Git allows you to quickly set up a tarball without creating a remote repository:
$ git archive --format=tar.gz --prefix=my_app-1.0/ -o my_app-1.0.tar.gz HEAD
- The tarball content should look like this:
$ tar tf my_app-1.0.tar.gz
my_app-1.0/
my_app-1.0/config.json
my_app-1.0/main.go
my_app-1.0/my_app.service
Building the RPM
First, we need to create the rpmbuild structure and place our tarball inside the source's directory:
$ rpmdev-setuptree
$ mv my_app-1.0.tar.gz ~/rpmbuild/SOURCES
Now, let’s build the RPM for Red Hat Enterprise Linux 8:
$ rpmbuild -ba my_app.spec
And that's it!
You should be able to install the RPM now and start the service:
$ sudo dnf install ~/rpmbuild/RPMS/x86_64/my_app-1.0-1.el8.x86_64.rpm
$ sudo systemctl start my_app
$ curl -L http://localhost:8081
You should see the content of our config.json (which, by the way, is under /etc/my_app).
But what if we have a new version of our application? We only need to increase the spec file version and build it again. DNF will see that there is a new update available.
And if you are using a package repository, you only need to run dnf update my_app.
Conclusion
If you want to delve more into the idea of incorporating RPM files in your deployments, I suggest looking at the RPM Packaging Guide and the Fedora Packaging Guidelines.
Also, a variety of exciting tools are available to help with the build process or even create repositories for you to use, such as mock, fedpkg, COPR, and Koji. These tools can help you in complex scenarios with multiple dependencies, complex steps, or multiple architectures.
Note that the workflow demonstrated in this article is also applicable to Fedora and to CentOS Stream.
Top comments (0)