I need to use supervisord in a docker container.
I want to keep the size of the container as small as possible.
Supervisord can be installed either using apt-get or python-pip.
Which method is recommended? and what should be thinking process while making these kind of decisions?
P.S Need supervisor because of legacy code. Can't do without it.
Supervisord version is not important.
Mostly depends on the version you want to install (if that relevant to you). apt-get's version are usually behind pip's version.
Also apt's version is tested and compatible with any other system dependency. Installing with pip could cause some conflicts with other already installed dependencies (most likely of your base OS is old)
If your goal is to keep image size small, make sure you install supervisor without leaving any cache (I.e: delete apt indices and /var/cache directory) or unwanted files (I.e: remove unneeded packages, use apt's install --no-install-recommends, use pip's install --no-cache) in a single Dockerfile RUN statement.
Related
I am reading dockerfile documentation.
I saw it mention the dockerfile would utilize cache better to improve build process.
So the documentation recommend that if you try to RUN apt-get update, merge the command to the following package install such as RUN apt-get update && apt-get install curl to avoid installing out-date package due to the cache.
I am wondering what if I download the same dockerfile but I build the docker image at different computers at different time.
Because the local cache in each computer, they still have chance to build different docker container even they run the same dockerfile.
I haven't encountered this problem. Just wonder is this possible and how to prevent it?
Thanks.
Debian APT repositories are external resources that change regularly, so if you docker build on a different machine (or repeat a docker build --no-cache on the same machine) you can get different package versions.
On the one hand, this is hard to avoid. Both the Debian and Ubuntu repositories promptly delete old versions of packages: the reason to apt-get update and install in the same RUN command is that yesterday's package index can reference package files that no longer exist in today's repository. In principle you could work around this by manually downloading every .deb file you need and manually dpkg --install them, skipping the networked APT layer.
On the other, this usually doesn't matter. Once you're using a released version of Debian or Ubuntu, package updates tend to be limited to security updates and bug fixes; you won't get a different major version of a package on one system vs. another. This isn't something I've seen raised as an issue, except that having a cached apt-get update layer can cause you to miss a security update you might have wanted.
Just a docker image is unchangeable. To ensure that the Dockerfile will generate the same image, you need to pin the exact software version in your install command.
I have to install a few dependencies on my docker container, I want to use python:3.6-alpine version to have it as light as possible, but apk package manager which comes with alpine is giving me trouble so I would like to get the apt-get package manager. I tried:
apk add apt-get
and it didnt work.
how can I get it on the container?
Using multiple package systems is usually a very bad idea, for many reasons. Packages are likely to collide and break and you'll end up with much greater mess than you've started with.
See this excellent answer for more detail: Is there a pitfall of using multiple package managers?
A more feasible approach would be troubleshooting and resolving the issues you are having with apk. apk is designed for simplicity and speed, and should take very little getting used to. It is really an excellent package manager, IMO.
For a good tutorial, I warmly recommend the apk introduction page at the Alpine Wiki site:
https://wiki.alpinelinux.org/wiki/Alpine_Linux_package_management
If you're determined not to use apk, and for the sake of experiment want try bringing up apt instead, as a first step, you'll have first to build apt from source: https://github.com/Debian/apt. Then, if it is produces a functional build (not likely since it's probably not compatible with musl libc), you'll have to wire it to some repositories, but Alpine repositories are only fit for apk, not apt. As you can see, this is not really feasible, and not the route you want to go to.
In order to ease the installation process of RabbitMQ, I want to use a simple, zero dependencies installer for erlang.
There is a great project on Github from the guys at RabbitMQ - erlang-rpm, but this is RPM only.
I'm aware of erlang-solutions, but it not a single, no dependencies installer.
EDIT: Adding some context here. I need this to be able to prepare a simple, offline install to my app, which needs RabbitMQ. Offline means NO access to internet for downloading dependencies.
Any ideas?
There is no Zero-dependency Erlang Ubuntu/Debian for RabbitMQ.
But the Erlang Solution package can be installed easily.
We built the Centos package because the dependencies are hard to install on Centos (if you don't want to use the epel)
If you want to create an offline setup, you can do it like for other packages (https://askubuntu.com/questions/974/how-can-i-install-software-or-packages-without-internet-offline). Or you can create your own package by building Erlang from source code.
Note also RabbitMQ has dependencies as socat
I have downloaded docker binary version 1.8.2 and copied that to my backup server (centos server) which doesn't have internet connectivity. I have marked this as executable and started the docker daemon as mentioned in [https://docs.docker.com/engine/installation/binaries/][1]. But it doesn't seem to get installed as a docker service. For all the commands, I have to execute as sudo ./docker-1.8.2 {command}. Is there a way to install docker-engine as a service? Currently sudo docker version shows command not found. I'm a newbie to docker setup. Please advise.
Why not download the rpm package (there are also centos 6 packages), copy to USB stick and then to your server and simply install it with rpm command and that's it. That way you'd get the same installation as if you were to run yum.
Of course you may have some dependencies missing, but you could download all of these as well.
Firstly, if you're downloading bare binaries on an enterprise linux, you're probably doing things in a very bad way. Immediately, you're breaking updates and consistency, and leaving your system in a risky, messy state.
Try using yumdownloader --resolve to get the docker installable and anything it needs.
A better option may be to mirror the installation artifacts, and grab it from the local mirror, but that's beyond the scope if you don't do this already.
We use travis-ci for continuous integration. I'm troubled by the fact that our build process takes too long (~30 minutes). We depend on several Ubuntu packages which we fetch using apt-get, among others python-pandas.
We also have some of our own debs which we fetch over HTTPS and dpkg install. Finally, we have several pip/pypi requirements, such as Django, Flask, Werkzeug, numpy, pycrypto, selenium.
It would be nice to be able to at least pre-package some of these requirements. Does travis support something like this? How can I prepackage some of these requirements? Is it possible to build a custom travis base VM and start the build from there (perhaps using docker)? Especially the apt-get requirements from the default Ubuntu precise repository as well as the pip requirements should be easy to include.
So while this question is already answered, it's doesn't actually provide a solution path. You can use cache directives in travis to cache your built packages for future travis runs.
cache:
directories:
- $HOME/.pip-cache/
- $HOME/virtualenv/python2.7
install:
- pip install -r requirements.txt --download-cache "$HOME/.pip-cache"
Now your package content is saved for your next travis build. You can similarly store slow-to-retrieve resources in other directories and cache them.
Currently Travis-CI doesn't support such a feature. There are related issues currently open though such as custom VMs, running Docker in an OpenVz container - (Spotify seems to have a somewhat working example links in this issue), using Linux Containers (LXC), using KVM.
Some of those have workarounds mentioned in the issues, I'd give those a try until something more substantial is supported by Travis-CI. I'd also suggest reaching out to Travis-CI support and see if they have any suggestions (maybe there's something coming out soon that could help).