I have been using Docker for a while now, it’s being used to provide services to friends and family.
I was always intimidated by the large amount of packages that were needed to get Docker and docker-compose up and running, and I did not have experience with Docker at the time (almost two years ago) so I decided to go the easy route and use the SlackBuilds.org scripts when I first needed to run a Docker container. I wrote a blog about that even, it explained how to run an Outline server to allow journalists to do their work in repressive countries but the article also shares the details how to build the Docker packages and run the daemon.
If you want to read some background information about Docker’s strength and what its use-cases are, I encourage you to start reading here: https://docs.docker.com/get-started/overview/ .
Essentially, Docker uses Linux kernel and filesystem capabilities to isolate an application and its dependencies from the host computer it is being executed on. Docker provides powerful means to connect multiple containers via internal (virtual) networking and can expose ports to the network outside of your container. It enables you to run applications reliably without having to worry about the underlying Operating system. You can even run Docker on a MS Windows computer but your containerized application running inside Docker will not be aware of that.
This is sometimes called ‘light-weight virtualization’ because unlike real virtualization solutions like QEMU, Virtual Box or VMWare, the containerized application still runs on your host’s kernel. This is why you can run a 32-bit container image on a 64-bit (Linux 64-bit kernel has that capability to execute 32-bit binaries) host but you cannot run a 64-bit image on a 32-bit host kernel.
Now that I am more familiar with Docker, have been running multiple services in containers for more than a year, and have created and published my own images (more about that later) I decided to create my own set of Docker packages. Having pre-built packages will make it a lot easier for people to start exploring the usefulness of Docker containers.
One thing upfront: I have significantly decreased the total amount of packages you need to run Docker.
I have combined the SlackBuilds.org packages ‘docker’, ‘docker-cli’, ‘docker-proxy’ and ‘tini’ into a single package called ‘docker’ and also added ‘docker-buildx’ to that docker package. Also, the re-write of docker-compose from Python to Go has the benefit that the run-time package dependencies for ‘docker-compose’ have been reduced from thirteen to zero.
Starting with my Docker packages
As stated in the subject: the packages I created are for Slackware-current only. If you want to compile this yourself on Slackware 14.2, I cannot guarantee success since I did not try compiling them there myself – but in any case you’ll have to build and install libseccomp from SlackBuilds.org, this is part of -current but not 14.2.
What you need from my repository to run Docker is: runc, containerd, docker and docker-compose. Four packages – that’s it.
If you want to be able to (re-)compile these packages, you will additionally need google-go-lang. After installing google-go-lang you need to logoff and login again (or run the command “source /etc/profile.d/go.sh” in your terminal) to give Google’s version of Go preference over the GCC version of Go that’s probably already installed on your computer.
The ‘docker’ package installation script will add a couple of lines to “/etc/rc.d/rc.local” and “/etc/rc.d/rc.local_shutdown” to make Docker start on boot and properly stop during shutdown of the computer. The docker rc script “/etc/rc.d/rc.docker” will initially be installed without the execute bit, so if you actually want to start using Docker you have to make the script executable. This is a one-time action. Future package upgrades will honor the executable status of that script.
# chmod +x /etc/rc.d/rc.docker
You can start the Docker daemon now if you don’t want to waste time with a reboot:
# /etc/rc.d/rc.docker start
The package installation will also trigger the creation of a new group called ‘docker’. If you want to be able to run and manage your Docker images and containers as your own non-root user account, you need to add your user account to this ‘docker’ group and then logoff/login again, and restart the docker deamon. Otherwise, all Docker operations can only be executed by the root user.
# gpasswd -a <your_useraccount> docker # /etc/rc.d/rc.docker restart
After doing all the prep work, your account added to the ‘docker’ group and the daemon running, it’s time for a first test. Run the following command:
$ docker run hello-world
You’ll see the following output:
Unable to find image 'hello-world:latest' locally latest: Pulling from library/hello-world 2db29710123e: Pull complete Digest: sha256:2498fce14358aa50ead0cc6c19990fc6ff866ce72aeb5546e1d59caac3d0d60f Status: Downloaded newer image for hello-world:latest Hello from Docker! This message shows that your installation appears to be working correctly ...
What you will have validated here is the proper functioning of your Docker installation:
- The Docker command-line client contacted the Docker daemon.
- The Docker daemon downloaded (or ‘pulled‘) the “hello-world” image from the Docker Hub.
- The Docker daemon created a new container from that image which runs the executable that produces the output you could read on your terminal just now.
- The Docker daemon streamed that output to the Docker client, which sent it to your terminal.
The “hello-world” image is of course trivial, but there are many more with real-life use-cases which you can find on Docker Hub, https://hub.docker.com/. You can download these images freely but if you want to upload (or ‘push’) an image which you created yourself, you’ll have to create an account on Docker Hub. Free acccounts allow the creation of one single private repository and unlimited public repositories.
Slackware Docker images
I have a repository on Docker Hub where I share my base images for stable Slackware versions (that’s the 14.2 release right now). Go get them at https://hub.docker.com/r/liveslak/slackware/tags . These “base images” are roughly 55 MB compressed, which means they are really basic. They are created using a script (create_slackware_docker_image.sh) which takes its inspiration both from the liveslak scripts and of Vincent Batts‘ work on Docker images for Slackware. Essentially, the script installs some packages into a package root, uses tar to put all of that in a tarball and loads the tarfile into Docker which will then make it into an actual image for you. That image wille be called “slackware:base_x64_14.2” (unless you specified a different architecture and release of course) and that’s what I uploaded to the Docker Hub.
My tiny Slackware docker-images are not really meant to be used as-is. Instead, they can act as the foundation for Slackware-based Docker images that you might want to build yourself – any Docker image starts with some existing base image and adds new layers on top. Base images like mine above don’t inherit from a lower-level image and are a special case, read more here: https://docs.docker.com/develop/develop-images/baseimages/
Now let’s pull that Slackware base image from the Hub and peek inside!
$ docker run -ti liveslak/slackware:latest /bin/bash -l
The “-ti” parameters tell docker to assign a pseudo-tty and run an interactive session on your terminal.
The convention for the image name is “username/imagename:tag” which shows that “liveslak” is the user who hosts the image on Docker Hub; “slackware” is the name of the image and it has a tag “latest” which means: just give me the latest version that I can get. For the slackware image, this means you get the 64-bit variant (I also have a 32-bit image) of Slackware 14.2.
The “/bin/bash -l” at the end is the command which Docker should run after bringing the container online. Remember, the base image contains nothing but a small amount of installed Slackware packages and does not start any application by itself. More complex Docker images may run all kinds of applications, some in the background and some meant to be interacted with such as the bash shell.
Running the above command yields this result:
Unable to find image 'liveslak/slackware:latest' locally latest: Pulling from liveslak/slackware 6c721e5d29bd: Pull complete Digest: sha256:352219d8d91416519e2425a13938f94600b50cc9334fc45d56caa62f7a193748 Status: Downloaded newer image for liveslak/slackware:latest root@b0264b9e59ff:/#
And we end up at the command prompt of our running container. The container user is ‘root’, it’s the only user in that base image. You do not have to enter a password.
Let’s play a bit:
root@b0264b9e59ff:/# ls /var/log/packages/ | wc -l 77 root@b0264b9e59ff:/# cat /etc/os-release NAME=Slackware VERSION="14.2" ID=slackware VERSION_ID=14.2 PRETTY_NAME="Slackware 14.2" ANSI_COLOR="0;34" CPE_NAME="cpe:/o:slackware:slackware_linux:14.2" HOME_URL="http://slackware.com/" SUPPORT_URL="http://www.linuxquestions.org/questions/slackware-14/" BUG_REPORT_URL="http://www.linuxquestions.org/questions/slackware-14/" root@b0264b9e59ff:/# exit logout $
Suppose you want want to download and use the 32-bit Slackware 14.2 base image instead. Then you would run:
$ docker run -ti liveslak/slackware:base_ia32_14.2 /bin/bash -l
Here ends my very brief introduction to Docker on Slackware. Let me know what you think of this! Is there anything you would like to see explained in more detail?
Eric
Update 2022-jan-13: I have added packages for Slackware 14.2 (32bit and 64bit) to my repository.
HI Eric,
thanks for this (well written, as usual) post and your work.
I provide flatpak for Slint since 2 December 2020 per users demands and with the reservations stated in https://slackware.uk/slint/x86_64/slint-14.2.1/source/flatpak/README. This allows users to run applications not available or difficult to build in Slint, and I use it to quickly assess new (for me) applications.
Which leads to this question: for what use cases docker vs flatpak is better suited in your opinion?
Cheers,
Didier
Hi Didier
From my own limited point of view and with the experiences in mind from my own daily work environment, Flatpak’s primary use-case is to provide Linux desktop applications as a single download with all dependencies included, so that the application binaries which were compiled on one Distribution will run un-modified on any Linux Distribution.
Docker on the other hand, aims at simplifying the deployment of backend/server services by stuffing all that’s needed to run a service in an image file and letting Docker take care of insulating that service from the host Operating System. But more importantly, docker-compose enables you to bundle a series of Docker images, each providing its own functionality, and providing the sum of that functionality to the users. Think of a database backend, an application server, a credential server, each in their own container, communicating with each other via a secure internal (virtual) network and exposed via a single or a few network ports. Other use-case: easily scale a service by adding more containers if the number of users increases and you need to re-distribute the load across more worker nodes.
Docker and Flatpak both use the smart capabilities of the Linux kernel and its userland to achieve this, like cgroups and namespaces.
Hi Didier!
I’m not Eric but I’ll contribute my $ 0.02 🙂
I think docker is more suited to running headless applications, like daemons, and like Eric said you can connect several containers using virtual networks so you can have a container running a mysql, another php-fpm and a third nginx serving wordpress, all working as a unit.
There’s also orchestration software like Kubernetes to run docker containers accross several physical servers.
Flatpak ans snaps seem more intended to run interactive/graphical applications and intergate with a desktop environment.
You can run daemons with flatpak/snaps and gui apps with docker but it’s not as easy.
Cheers!
PS: I’m richarson on LQ
Hi Eric,
you must have read my thoughts. I have run docker in the past with poste.io and other containers. I was struggling to re-install docker from slackbuilds.org today when I saw your email. The google-go-lang slackbuild failed. Hopefully I’ll have more luck with your pre-compiled packages.
Keep up the good work!
Note that the packages are for Slackware-current (soon to be 15.0) only. I don’t know what happens if you try to compile these on Slackware 14.2.
Luckily I had a spare machine, and can confirm your packages work well on current (32 bit). I wasn’t going to try “15.0” yet, but I like what I see so far, and look forward to “go live” day. I have a container running citadeldotorg/citadel , but might not use it again. Just nostalgia for the old citadel I used to run on slackware 12.2
Thanks to all’y’all for the discussion.
I’ve never tried Docker but it sounds like it might fit a few of my servers instead of running dedicated machines with the ‘kitchen sink’ exposed to the internet.
I’ll have to do some reading and try to graduate from the 20th century 🙂
— kjh
Wow, quite nice work. I’ll need to take a look when time allows.
Thanks
Hi Eric
I’ve been running the cf docker packages from Conraid for a while now (been deprecated for a few months as well and no longer maintained in his repo).
docker version
Client:
Version: 19.03.14
API version: 1.40
Go version: go1.15.6
Git commit: 5eb3275d4006e4093807c35b4f7776ecd73b13a7
Built: Sat Dec 12 20:03:57 2020
OS/Arch: linux/amd64
Experimental: false
Server:
Engine:
Version: 19.03.14
API version: 1.40 (minimum version 1.12)
Go version: go1.15.6
Git commit: 5eb3275d4006e4093807c35b4f7776ecd73b13a7
Built: Sat Dec 12 20:03:30 2020
OS/Arch: linux/amd64
Experimental: false
containerd:
Version: 1.5.2
GitCommit: 4a4bb851f5da563ff6e68a83dc837c7699c469ad
runc:
Version: 1.0.0-rc8
GitCommit: 425e105d5a03fabd737a126ad93d62a9eeede87f
docker-init:
Version: 0.18.0
GitCommit:
I’ve been using pip install/upgrade to keep docker-compose going. Do you foresee any issue with running my current containers by replacing the cf packages with yours?
I am running an even older version of Docker on my server (using packages compiled from the SBo scripts) because I thought it’s too much work chasing almost 20 packages to be updated. But with the number of packages now reduced to four, I am going to plan that upgrade.
In summary: I don’t know what will happen after the upgrade, but containers should not be affected by the newer version of docker and docker -compose. New syntax will become available to your Dockerfiles but I don’t think there will be backwards compatibility issues. Looking at https://docs.docker.com/compose/compose-file/compose-versioning/ , the compose file format is unchanged since Docker 19.03.0.
Thanks Eric, I’ve upgraded and no issues. I just need to remove unused packages now and test portainer.io.
Thanks for the great work dear Eric,
Just surprised today when saw the packages are there available to upgrade in slackpkg+ alien repo and felt great for it.
Also in the docker hub you saved us lots of energy by putting those base images there, It was really hard to make a choice between non-slack base images as the foundation of almost anything as a slacker.
Cheers!
Good! I hope it’s useful for you. Once Slackware 15.0 is released, 15.0 base images will be added for 32-bit and 64-bit.
I’ve uploaded a sample Dockerfile which expands on the base image and creates a new image with compilers and such (a nice small build environment basically), creates a user account and starts a bash shell.
See http://www.slackware.com/~alien/tools/docker/Dockerfile.slackware-buildnode
You can build an image from this using:
$ docker build –no-cache -t slackware-buildnode http://www.slackware.com/~alien/tools/docker/Dockerfile.slackware-buildnode
And then run a container based on this image, you should end up at the commandline of the contaier as user ‘live:
$ docker run -i -t slackware-buildnode
Thanks a huge pile Eric! I love Docker, been playing with it this past year, I setup a sandbox in my home network to learn it, cause I like to do things that way. Containerization is the future, I think it’s already arrived. I’m going to try your package(s) this week.
I so appreciate your efforts in this community, thank you from Western Canada.
At Work I use Docker on Windows and they recently changed their license model and we have to pay now. Is licensing not an issue on Linux at all? Even kubernetes recommends a different Container runtime now. ContainerD etc.
Docker, the runtime, itself has had no license change. I think you are referring to Docker Destop which is a specific product from Docker the company, and there have been some changes here. While free previously, it is now only free for small businesses. Personally, I don’t see any issue with Docker charging for the Desktop product, especially when it only applies to large orgs which can easily afford the very reasonable cost.
On Linux, users mostly use docker-compose or UI’s like portainer to manage their docker images and containers.
As Robby already said, the “Docker Desktop” on Windows is a different product, since on Windows you have do do a lot more to run Linux containers. Docker used to use the Microsoft HyperV and switched to Windows Subsystem for Linux. I guess they want to cash in on their past efforts to develop that.
One of the packages I have for Slackware is containerd actually. On Linux you do not pay for the product, they are all open source. You only pay if you want to let Docker host a private repository of your Docker images on their Hub, but that is a choice.
Packages for Slackware 14.2 are now also available in my repository.
Same four run-time: containerd, runc, docker and docker-compose. Additionally google-go-lang and go-md2man in case you want to compile them yourself.
Hello alienbob,
Any chance to add your docker packages for Slackware 15.0 anytime soon? Thanks.
Where did you look for them? They are there since the release of Slackware 15.0.
Using slackpkg+ with added “alienbob” and “restricted” repos. However, “slackpkg search” for your 4 a.m. packages returns no result.
No such problem here:
I think slackware.nl had an outage last night. Appears to be back for me this morning.
Yeah when I woke up my mailbox was full of warnings. The httpd process was hung up, I restarted it and all was well again.
Hi Alienbob,
I struggled a bit to install docker on 15.0, and at the end I understood that the libseccomp package needed to be installed as well. After that docker could run without terminating with errors.
In the documentation on this page, you mentioned that this package was required for 14.2 only, but apparently it was required on my 15.0 slackware system.
Thanks for your great documentation on this, now I can run docker and docker compose on Slackware.
Alexandre
Hi Alexandre!
libseccomp is part of Slackware 15.0, that’s why it’s not “required” in the sense that Slackware is supposed to be installed full and you should already have it.
For 14.2 on the other hand, Eric provides libseccomp because it is not part of that Slacware version.
Cheers!
Hi, Eric!
Do you also have some ideas on introducing Kubernetes on Slackware?
Hi Janis,
I am not going to touch Kubernetes. I do not use it, and it wants to see systemd.
loadinternal: cannot find runtime/cgo
./man/md2man-all.sh: line 21: go-md2man: command not found
Makefile:68: recipe for target ‘manpages’ failed
make: *** [manpages] Error 127
— docker daemon
go: downloading github.com/matttproud/golang_protobuf_extensions v1.0.2-0.20181231171920-c182affec369
install: cannot stat ‘moby-20.10.18/bundles/dynbinary-daemon/dockerd’: No such file or directory
./docker.SlackBuild FAILED at line 365
root@14.2 docker $
# github.com/docker/docker/vendor/archive/tar
vendor/archive/tar/common.go:541:32: undefined: any
vendor/archive/tar/strconv.go:204:15: undefined: strings.Cut
vendor/archive/tar/strconv.go:254:20: undefined: strings.Cut
vendor/archive/tar/strconv.go:276:13: undefined: strings.Cut
fatal: not a git repository: ‘/tmp/build/tmp-docker/src/github.com/krallin/tini/.git’
fatal: not a git repository: ‘/tmp/build/tmp-docker/src/github.com/krallin/tini/.git’
Stop posting errors from your build logs. I do not see a question in there. This is just pollution of the comments section.
If you fail in compiling, just install the packages that I also provide. If you still want to compile them yourself, you probably need to read this article and my comments better.
I had some problems getting Docker to work behind a proxy on Slackware 15. I set the proxy in /etc/environment (also had to set it in /etc/wgetrc for slackpkg) and also ~/.docker/config.json but still had timeouts. The only thing that helped was setting the proxy in /etc/rc.d/rc.docker before starting the docker daemon. Maybe there is a better way to do this.
This article ( https://docs.docker.com/config/daemon/systemd/#httphttps-proxy ) instructs you to add the proxy settings to /etc/docker/daemon.json – have you tried that?
Hi Eric,
When you published this post, I took a pass on it.
Fast forward more than 2 years later, and I need to have docker installed on my Slacware 15.0 machine. I remembered that you did something about it, searched your blog and voilà, docker was set up in no time on 15.0.
Thank you for your invaluable and timeless articles.
Thanks for sharing gegechris99 🙂
Glad to hear that my writings were useful.