I'm following the userguide on dockerlinks
I followed these steps as follows :
sudo docker run -d --name db training/postgres
sudo docker run -d -P --name web --link db:db training/webapp python app.py
sudo docker inspect -f "{{ .HostConfig.Links }}" web
In this last step, the guide asserts the return value of [/db:/web/db]
What I'm receiving is <no value>
Why are the containers not linking?
The apt-get repositories include docker version 1.0.1, but HostConfig.Links doesn't show up in the documentation until version 1.3 (See the version switcher under the "Search the Docs").
You can verify that this is the problem by running docker --version.
If you want the latest version of docker (1.4), you should uninstall docker.io and follow the directions here: http://docs.docker.com/installation/ubuntulinux/#docker-maintained-package-installation . In particular see the note, as you can just run:
curl -sSL https://get.docker.com/ubuntu/ | sudo sh
That will also give you some other nice features that are missing from the version in the Ubuntu repository, such as exec.
Related
I am trying to run docker image with gitlab on my Raspberry PI.
Versions:
Raspbian 10 (buster)
Docker 20.10.8, API 1.41
Gitlab CE 13.10.0-ce.0 from [this][1] image, ulm0/gitlab 12.7.2
I am using simply docker command to run gitlab:
sudo docker run --name gitlab \
-p 10080:80 -p 10022:22 -p 10443:443 \
-v /srv/gitlab/config:/etc/gitlab \
-v /srv/gitlab/logs:/var/log/gitlab \
-v /srv/gitlab/data:/var/opt/gitlab -v \
/srv/gitlab/logs/reconfigure:/var/log/gitlab/reconfigure \
ulm0/gitlab
After running a command, in sudo docker logs gitlab I've got something like this:
Configure GitLab for your system by editing /etc/gitlab/gitlab.rb file
And restart this container to reload settings.
To do it use docker exec:
docker exec -it gitlab vim /etc/gitlab/gitlab.rb
docker restart gitlab
For a comprehensive list of configuration options please see the Omnibus GitLab readme
https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/README.md
If this container fails to start due to permission problems try to fix it by executing:
docker exec -it gitlab update-permissions
docker restart gitlab
but after running docker exec -it gitlab update-permissions I've got this:
Error response from daemon: Container 110f1def3f669d8d180bf552aa63e50c0e4c857f8bd1ab2745a677454fef04b0
is restarting, wait until the container is running
when I ran command with permissions right after container stared, I got unable to upgrade to tcp, received 409 and now I stuck, because I can not even log into my machine, it's restarting all the time. I tried to change port to more custom, but it's also dead.
I used latest version, but I have changed it to ulm0/gitlab:12.10.0 and it works. Sounds like a bug in a new version.
I would like to setup cuda using the following code:
docker run -ti --rm --runtime=nvidia -e NVIDIA_VISIBLE_DEVICES=0 nvidia/cuda
I Kept getting these Errors:
Command 'docker' not found, but can be installed with:
snap install docker # version 18.06.1-ce, or
apt install docker.io # version 18.09.7-0ubuntu1~19.04.5
See 'snap info docker' for additional versions.
I tried to google these Errors, but failed.
System Environment: Ubuntu Desktop 19.04
I should explain that this is a clean System I'm currently using.
I should tell you one thing that, installing anything with docker comes with a prerequisite, which is that you should install docker first.
You can find the tutorials on how you could install docker in the following link:
How to install Docker
And then you could install Nvidia compiled docker container with the following command:
docker pull nvidia/cuda
docker run -ti --rm --runtime=nvidia -e NVIDIA_VISIBLE_DEVICES=0 nvidia/cuda
which was referenced from Nvidia CUDA Docker Hub and Nvidia CUDA GitHub page
I recently found out about Podman (https://podman.io). Having a way to use Linux fork processes instead of a Daemon and not having to run using root just got my attention.
But I'm very used to orchestrate the containers running on my machine (in production we use kubernetes) using docker-compose. And I truly like it.
So I'm trying to replace docker-compose. I will try to keep docker-compose and using podman as an alias to docker as Podman uses the same syntax as docker:
alias docker=podman
Will it work? Can you suggest any other tool? I really intend to keep my docker-compose.yml file, if possible.
Yes, that is doable now, check podman-compose, this is one way of doing it, another way is to convert the docker-compose yaml file to a kubernetes deployment using Kompose. there is a blog post from Jérôme Petazzoni #jpetazzo: from docker-compose to kubernetes deployment
Update 6 May 2022 : Podman now supports Docker Compose v2.2 and higher (see Podman 4.1.0 release notes)
Old answer:
Running docker-compose with Podman as a normal user (rootless)
Requirement: Podman version >= 3.2.1 (released in June 2021)
Install the executable docker-compose
curl -sL -o ~/docker-compose https://github.com/docker/compose/releases/latest/download/docker-compose-$(uname -s)-$(uname -m)
chmod 755 ~/docker-compose
Alternatively you could also run docker-compose in a container image (see below).
Run
systemctl --user start podman.socket
Set the environment variable DOCKER_HOST
export DOCKER_HOST=unix://$XDG_RUNTIME_DIR/podman/podman.sock
Run
~/docker-compose up -d
Running docker-compose with Podman as root
Requirement: Podman version >= 3.0 (released in February 2021)
Follow the same procedure but remove the flag --user
systemctl start podman.socket
Running docker-compose in a container image
Use the container image docker.io/docker/compose to run
docker-compose
podman \
run \
--rm \
--detach \
--env DOCKER_HOST=unix://$XDG_RUNTIME_DIR/podman/podman.sock \
--security-opt label=disable \
--volume $XDG_RUNTIME_DIR/podman/podman.sock:$XDG_RUNTIME_DIR/podman/podman.sock \
--volume $(pwd):$(pwd) \
--workdir $(pwd) \
docker.io/docker/compose \
--verbose \
up -d
(the flag --verbose is optional)
The same command with short command-line options on a single line:
podman run --rm -d -e DOCKER_HOST=unix://$XDG_RUNTIME_DIR/podman/podman.sock --security-opt label=disable -v $XDG_RUNTIME_DIR/podman/podman.sock:$XDG_RUNTIME_DIR/podman/podman.sock -v $(pwd):$(pwd) -w $(pwd) docker.io/docker/compose --verbose up -d
Regarding SELINUX: Runnng Podman with SELINUX is preferable from a security point-of-view, but I didn't get it to work on a Fedora 34 computer so I disabled SELINUX by adding the command-line option
--security-opt label=disable
Troubleshooting tips
Test the Docker REST API
A minimal check to see that the Docker REST API is working:
$ curl -H "Content-Type: application/json" \
--unix-socket $XDG_RUNTIME_DIR/podman/podman.sock \
http://localhost/_ping
OK$
Avoid short container image names
If any of your docker-compose.yaml or Dockerfile files contain a short container image name, for instance
$ grep image: docker-compose.yaml
image: mysql:8.0.19
$
$ grep FROM Dockerfile
FROM python:3.9
$
edit the files to use the whole container image name instead
$ grep image: docker-compose.yaml
image: docker.io/library/mysql:8.0.19
$
$ grep FROM Dockerfile
FROM docker.io/library/python:3.9
$
Most often short names have been used to reference DockerHub Official Images
(a catalogue) so a good guess would be to prepend the container image name with docker.io/library/
There are currently many different container image registries, not just DockerHub (docker.io). Writing the whole container image name is thus a good practice. Podman might complain otherwise depending on how Podman is configured.
Rootless users can't bind to ports below 1024
If for instance
$ grep -A1 ports: docker-compose.yml
ports:
- 80:80
$
edit docker-compose.yaml so that the host port number >= 1024, for instance 8080
$ grep -A1 ports: docker-compose.yml
ports:
- 8080:80
$
An alternative solution is to adjust net.ipv4.ip_unprivileged_port_start with sysctl (see Shortcomings of Rootless Podman)
In case Systemd is missing
Most Linux distributions use Systemd where you would preferably start the Podman service (providing the REST API) by "starting" the Podman socket
systemctl --user start podman.socket
or
systemctl start podman.socket
but in case Systemd is missing you could also start the Podman service directly
podman system service --time 0 unix:/some/path/podman.sock
Systemd gives the extra benefit that the Podman service is started on demand with Systemd socket activation and stops after some time of inactivity.
Caveat: Swarm functionality is missing
A difference to Docker is that the functionality relating to Swarm is not supported when using docker-compose with Podman.
References:
https://www.redhat.com/sysadmin/podman-docker-compose
https://github.com/containers/podman/discussions/10644#discussioncomment-857897
Ensure Podman is installed on your machine.
You can install Podman Compose in a terminal with the following command:
pip3 install https://github.com/containers/podman-compose/archive/devel.tar.gz
cd into the directory your docker-compose file is located in
Run podman-compose up
See the following link for a decent introduction.
My centos version and docker version（install by yum）
Use docker common error in container
My docker run command:
docker run -it -d -u root --name jenkins3 -v /var/run/docker.sock:/var/run/docker.sock -v $(which docker):/usr/bin/docker docker.io/jenkins/jenkins
but，its error when I exec docker info in jenkins container
/usr/bin/docker: 2: .: Can't open /etc/sysconfig/docker
Exposing the host's docker socket to your jenkins container will work with
-v /var/run/docker.sock:/var/run/docker.sock
but you will need to have the docker executable installed in your jenkins image via a Dockerfile.
It is likely the example you are looking at is already using a docker image. A quick google search brings up https://jpetazzo.github.io/2015/09/03/do-not-use-docker-in-docker-for-ci/ whose example uses a docker image (already has the executable installed):
docker run -v /var/run/docker.sock:/var/run/docker.sock \
-ti docker
Also note from that same post your exact issue with mounting the binary:
Former versions of this post advised to bind-mount the docker binary from the host to the container. This is not reliable anymore, because the Docker Engine is no longer distributed as (almost) static libraries.
I am trying to run the JHipster in docker container and followed the steps mentioned in https://jhipster.github.io/installation/.
> docker pull jhipster/jhipster
> mkdir ~/jhipster
> docker run --name jhipster -v ~/jhipster:/home/jhipster/app -v ~/.m2:/home/jhipster/.m2 -p 8080:8080 -p 9000:9000 -p 3001:3001 -i -t jhipster/jhipster
As I am running it in interactive mode it showing the JHIPSTER ASCII art and shows :: JHipster :: Running Spring Boot :: :: http://jhipster.github.io ::. Thats it.
When I docker ps:
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
f0015bd63658 jhipster/jhipster "tail -f /home/jhipst" 2 minutes ago Up 2 minutes 0.0.0.0:3001->3001/tcp, 0.0.0.0:8080->8080/tcp, 0.0.0.0:9000->9000/tcp jhipster
Now when I try to access localhost:8080 I am getting This page isn't working ERR_EMPTY_RESPONSE.
I checked in my ~/jhipster folder, there is nothing.
I logged into container with docker exec -it jhipster bash, there is nothing in app folder.
OS: MacOS
Docker Version: Docker version 1.12.5, build 7392c3b
docker-compose version 1.9.0, build 2585387
What am I missing?
When using the JHipster Docker image, all of the software requirements are installed but you still need to run the generator and choose your options.
Following along the installation documentation, you should log into the container, change to the app folder, and run jhipster:
docker container exec -it jhipster bash
cd /home/jhipster/app
jhipster
Once your application is created, you can run all the normal webpack/gulp and maven commands. For example, the following commands will start your backend and your frontend (run in separate terminals).
./mvnw
yarn start