I am using a docker image from by Continuum Analytics in my .gitlab-ci.yml file, in order to use conda (as well explained here)
Everything works fine except for one detail: I cannot get the latest version of a package published on a specific channel (this one, but that shouldn't matter) - the latest version is 0.2.6, but the version 0.2.3 is installed.
If I specify in my environment.yaml file that I want a specific version:
dependencies:
- presamples>=0.2.6
I get the following error during build:
ResolvePackageNotFound:
- presamples[version='>=0.2.6']
Are Continuum Analytics docker image not able to download versions of packages that were created after the docker image was created? This may be a silly question, I don't know anything about docker...
Related
I have docker-compose 1.25.4 on a system, and docker 19.03. How do I know which version of Compose file format it supports, without trying a bunch or searching through release notes etc?
I determined by trial and error that the highest Compose file format version that docker-compose 1.25.4 supports is 3.7. Therefore, my docker-compose.yml requires version: "3.7".
But what if I need to determine this programmatically? Or reliably, without trial and error, and without looking at release notes?
The docs at https://docs.docker.com/compose/compose-file/compose-versioning/ suggest that highest version should be 3.8 but this does not work. Indeed the release notes indicate that 3.8 became supported as of docker-compose 1.25.5.
I looked through various docker-compose commands and could not spot anything that would say "This version of docker-compose supports Compose file version up to x.y".
I figured out that there is no way to find this out via the cli.
You need to check the docker-compose github releases for this.
For example on Ubuntu: v1.25.0 version of docker-compose which is currently the latest and gets to be installed by default, but it is compatible with the 3.7 at highest.
https://github.com/docker/compose/releases/tag/1.25.0
The Compose file format compatibility matrix part is the interesting here.
When starting a .NET 5 project locally there is an automatic roll forward, meaning when starting the project the runtime will choose the newest minor/patch version installed on the system.
For deploy to production I use docker with a typical Dockerfile with lines like
FROM mcr.microsoft.com/dotnet/sdk:5.0
and
FROM mcr.microsoft.com/dotnet/aspnet:5.0
When typing "dotnet --info" on the server where the docker image is running on I always get version "5.0.0".
I would like to know if I have to enter the correct minor/patch versions manually in the Dockerfile each time a new version is released or if there is a version specifier to install those small versions with automatic roll forward.
mcr.microsoft.com/dotnet/sdk:5.0 is a floating tag. It always refers to the latest patch in that major.minor release:
The tag is updated to always reference the most recent patch that is currently available for the Major.Minor release.
For example, if you inspect the docker image today, you should see this is a 5.0.102 SDK and 5.0.2 Runtime image:
$ podman inspect mcr.microsoft.com/dotnet/sdk:5.0 --format='json' | jq '.[0].Config.Env'
[
"PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin",
"ASPNETCORE_URLS=",
"DOTNET_RUNNING_IN_CONTAINER=true",
"DOTNET_VERSION=5.0.2",
"ASPNET_VERSION=5.0.2",
"DOTNET_SDK_VERSION=5.0.102",
"DOTNET_USE_POLLING_FILE_WATCHER=true",
"NUGET_XMLDOC_MODE=skip",
"POWERSHELL_DISTRIBUTION_CHANNEL=PSDocker-DotnetSDK-Debian-10"
]
If you are seeing that this is still 5.0.0 on you server, you might be using an older container. By default docker run will run the image last pulled, without checking for an update.
You might need to docker pull to explicitly update the image, or use docker run --pull=always to make sure you are running the latest container image.
I installed Docker on a Red Hat Enterprise Linux Server 7.5 (Maipo) system:
docker version
Version: 1.13.1
API version: 1.26
Package version: docker-1.13.1-58.git87f2fab.e17.x86_64
OS/Arch: linux/amd64
Now if I try to run a docker image, I get errors similar to this:
docker run docker.io/jupyter/datascience-notebook
tini: error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory
I have searched for help and have already taken a multitude of possible actions:
libraries seem to be linked correctly
all libraries are up to date
Hello-World example works
I also came across information saying that running containers from docker.io / hub.docker.com under RHEL is not supported - which I don't really get, as main purpose of docker is to enable running programs independent from their OS...?
https://access.redhat.com/solutions/1408853 Does this mean using docker under RHEL does not really provide me with the possibility of easily deploying/sharing a docker-image with non-RHEL users?
Also, does this mean I can only access and use official RHEL-docker images?
https://access.redhat.com/containers/?start=90#/search/
As I wanted to use docker to have ready-to-go environments with R-Python/Jupyter/H2o (and similar), I'm disappointed because I could not find suitable images for RHEL there.
So, my questions would be:
Is it possible to run docker.io / hub.docker.com images under RHEL7.5?
if not, could I share my own created docker images under RHEL7.5 to other users with different OS versions?
Are there other projects / sites to share docker-images for data science purposes on RHEL?
Would you agree that my next step would be: building my own docker-image, adding R/Python/jupyter step by step?
Best regards,
workah0lic
This error message
tini: error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory
comes from within the container image. It could be a corrupted container image, but the message is also printed when the glibc dynamic linker determines that the kernel features are not sufficient for loading libc.so.6. I looked at the image (digest is sha256:79f929bd0e58fa9cb238dceda48b0c8360e748d09b476b429216c93dac0bd783), and it appears to require kernel 3.2, so the Red Hat Enterprise Linux 7 kernel version of 3.10 should be sufficient.
In fact, I cannot reproduce this problem with kernel-3.10.0-862.6.3.el7.x86_64 and docker-1.13.1-58.git87f2fab.el7.x86_64. You could try to run this command to obtain additional information about dynamic linker behavior:
docker run -e LD_DEBUG=all docker.io/jupyter/datascience-notebook
I've been looking around for people trying to do such madness but can't find anything.
What I'm trying to do is upgrade from an old, unmaintained version of Gitlab 7.4.2 that was running on a server to a Docker version on 10.4.
I did my backup correctly with 7.4 but obviously as I'm trying to unpack it, I get the following :
Your current GitLab version (10.4.2) differs from the GitLab version in the backup!
Please switch to the following version and try again:
version: 7.4.2
I'm not sure of the procedure I should do next but have a few ideas I'd like to run by you here to see which is the easiest/most doable.
Upgrade my bare-metal server gradually from 7.4 to 8.x, then to 9.x to have the minimum Docker version present on Docker Hub. Then do a backup and repeat the process on Docker.
Force (how?) the Docker version to take this backup anyway
An other solution maybe ?
Thanks in advance for any help.
Madness indeed....
The brute force take of upgrading here is probably the way to go, as this is by far the safest one.
The only alternative I can offer is to migrate your source instance to the omni-bus installation of the same version an then let the package manager deal with the mess and update to the latest version.
But you should prepared for problems. Non omni-bus to omni-bus installations are not tested. If you want to try it anyway, here is the upgrade guide for the omni-bus versions.
If you have then the newest version you can simply export and import it into the docker instance as the docker image simply contains a omni-bus instance.
You can not upgrade Gitlab directly and must upgrade it step by step to the next major release: 7 -> 8 -> 9 -> 10.
You can see more information in the link below:
[https://docs.gitlab.com/ee/policy/maintenance.html#upgrade-recommendations][1]
and execute the following commands:
sudo docker stop gitLab
sudo docker rm gitLab
You can see more information in the link below:
[https://docs.gitlab.com/omnibus/docker/README.html#upgrade-gitlab-to-newer-version][1]
and after executing 2 above commands you can change the GitLab version that existing in the content of the docker-compose.yml .
examlpe:
gitlab:
restart: always
image: sameersbn/gitlab:11.11.0
depends_on:
- redis
- postgresql
to chenged:
gitlab:
restart: always
image: sameersbn/gitlab:12.7.6
depends_on:
- redis
- postgresql
and execute the following command:
sudo docker-compose up -d
Repeat these stages and Step by step between the GitLab versions to get the desired version.
I would like to make sure that I'm using version 3 of the compose file format. However, on https://docs.docker.com/compose/compose-file/ I was not able to find out how to do this.
My Docker version is 17.04.0-ce, build 4845c56, and my Docker-Compose version is docker-compose version 1.9.0, build 2585387. I'm not sure since when version 3 of the compose file format was introduced, however. How can I find this out?
It's on your docker-compose.yml file. First parameter is Docker Compose version.
version: '3'
Docker Compose version file 3 was introduced in release 1.10.0 of Docker Compose and 1.13.0 release of Docker Engine.
Here you can see release notes for Docker Compose 1.10.0 which introduces version file 3: https://github.com/docker/compose/releases/tag/1.10.0
The docker compose version 3 syntax requires docker version 1.13 and docker-compose version 1.10 (see the release notes). See the release notes for the version compatibility matrix and upgrade instructions.
Note that the version 3 syntax is designed for docker swarm mode, and it was first supported with the docker stack deploy in docker release 1.13. There's not much reason to upgrade to the version 3 syntax if you are still using docker-compose itself.
See also the compose file versioning page that describes the differences between the different yml versions.