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.
Related
I'm new to Docker and I'm not very experienced in SSL/certificates etc.
I'm working on a web application that lets the user log in to JIRA via JIRA API to do things. This works on my computer and I don't get any SSL errors. However, when I run it in a Docker container I get
ssl.SSLError: [SSL: WRONG_SIGNATURE_TYPE] wrong signature type error.
My friend ran the exact same Dockerfile in his computer and created a container and it works which is confusing.
I checked the requests library version on my computer and compared it to the one in Docker container but they are the same. What could be the problem? Thank you
Note: I use Windows
Faced similar problem.
Find the solution here
Just to sum up:
There is missing dependencies inside container which your own system already has. You should install them inside docker.
Idk how but pyopenssl library should be install to
So, you need to add:
RUN apt-get update \
&& apt-get install openssl \
&& apt-get install ca-certificates
In your Dockerfile
And add:
pyopenssl==19.1.0
To your requirements.txt
If you don't use requirements.txt just add:
RUN pip install pyopenssl
To your Dockerfile
Hope it'll help
Similar issue happened to me - python tls requests were working fine on my host, but failed with WRONG_SIGNATURE_TYPE once I dockerized my script.
The issue seems to stem from where requests lib uses older TLS stacks with OpenSSL 1.1.1pre9.
I noticed rolling back to python:3.5.3 stopped the error, however for compatibility with newer versions the solution posted in github issue thread worked fine.
i.e. import the TLSAdapter, use it to setup a requests session, then start making requests.
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.
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.
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).