microk8s in docker container - docker

For the automatic testing of my code I would like to add a microk8s in my docker-compose setup for testing. Hence, I'd like to install microk8s in docker environment
I got snap running in the docker container using the following commands from the web
FROM ubuntu:18.04
ENV container docker
ENV PATH /snap/bin:$PATH
ADD snap /usr/local/bin/snap
RUN apt-get update
RUN apt-get install -y snapd squashfuse fuse
RUN systemctl enable snapd
STOPSIGNAL SIGRTMIN+3
CMD [ "/sbin/init" ]
snap script
!/bin/sh -e
while ! kill -0 $(pidof snapd) 2>/dev/null; do
echo "Waiting for snapd to start."
sleep 1
done
/usr/bin/snap $#
and building docker
docker build -t snapd .
and run
docker run --name=snapd -ti -d --tmpfs /run --tmpfs /run/lock --tmpfs /tmp --privileged -v /lib/modules:/lib/modules:ro snapd
up to here everything is fine.
However if try to install microk8s via snap it fails
snap install microk8s --classic --channel=1.18/stable
2020-04-27T14:22:39Z INFO Waiting for restart...
error: cannot perform the following tasks:
- Run install hook of "microk8s" snap if present (run hook "install": execv failed: Permission denied)
checking snap systemctl status snapd.service gives me
Apr 27 15:14:32 8985fc7fc5cb snapd[489]: helpers.go:961: cannot retrieve info for snap "microk8s": cannot find installed snap "microk8s" at revision 1341: missing file /sn
ap/microk8s/1341/meta/snap.yaml
Apr 27 15:14:33 8985fc7fc5cb snapd[489]: helpers.go:105: error trying to compare the snap system key: system-key versions not comparable
Apr 27 15:14:33 8985fc7fc5cb snapd[489]: helpers.go:961: cannot retrieve info for snap "microk8s": cannot find installed snap "microk8s" at revision 1341: missing file /sn
ap/microk8s/1341/meta/snap.yaml
Apr 27 15:14:33 8985fc7fc5cb systemd[1]: Started Snappy daemon.
Apr 27 15:15:08 8985fc7fc5cb snapd[489]: handlers.go:495: Reported install problem for "microk8s" as e11fe0c4-8899-11ea-a8e2-fa163ee63de6 OOPSID

I found a (for me) somewhat satisfying answer is to use k3s
A German description can be found here
The key is the following docker-compose.yml
version: '3'
services:
server:
image: rancher/k3s:v0.8.1
command: server --disable-agent
environment:
- K3S_CLUSTER_SECRET=somethingtotallyrandom
- K3S_KUBECONFIG_OUTPUT=/output/kubeconfig.yaml
- K3S_KUBECONFIG_MODE=666
volumes:
- k3s-server:/var/lib/rancher/k3s
# get the kubeconfig file
- .:/output
ports:
- 6443:6443
node:
image: rancher/k3s:v0.8.1
tmpfs:
- /run
- /var/run
privileged: true
environment:
- K3S_URL=https://server:6443
- K3S_CLUSTER_SECRET=somethingtotallyrandom
ports:
- 31000-32000:31000-32000
worker:
image: rancher/k3s:v0.8.1
tmpfs:
- /run
- /var/run
privileged: true
environment:
- K3S_URL=https://server:6443
- K3S_CLUSTER_SECRET=somethingtotallyrandom
volumes:
k3s-server: {}

(Just for completeness but I don't accept this answer, if so it my own but suggested by #David Maze) You can use kind Kubernetes in Docker. it was primarily developed for testing docker itself.

Related

Unable to start Flink JobManager container in Docker

I am unable to start a Flink JobManager Docker container on M1 MacBook running Monterey. Below is the docker command pulled from the Flink Docs and the resulting java.io.IOException
docker run \
--rm \
--name=jobmanager \
--network flink-network \
--publish 8081:8081 \
--env FLINK_PROPERTIES="${FLINK_PROPERTIES}" \
flink:1.16.0-scala_2.12 jobmanager
INFO org.apache.flink.runtime.entrypoint.ClusterEntrypoint [] - Shutting StandaloneSessionClusterEntrypoint down with application status FAILED. Diagnostics java.io.IOException: Could not create the working directory /tmp/jm_ba47b82cf8d85068faa1c41d30126b5d.
at org.apache.flink.runtime.entrypoint.WorkingDirectory.createDirectory(WorkingDirectory.java:58)
at org.apache.flink.runtime.entrypoint.WorkingDirectory.<init>(WorkingDirectory.java:39)
at org.apache.flink.runtime.entrypoint.WorkingDirectory.create(WorkingDirectory.java:88)
at org.apache.flink.runtime.entrypoint.ClusterEntrypointUtils.lambda$createJobManagerWorkingDirectory$2(ClusterEntrypointUtils.java:241)
at org.apache.flink.runtime.entrypoint.DeterminismEnvelope.map(DeterminismEnvelope.java:49)
at org.apache.flink.runtime.entrypoint.ClusterEntrypointUtils.createJobManagerWorkingDirectory(ClusterEntrypointUtils.java:239)
at org.apache.flink.runtime.entrypoint.ClusterEntrypoint.initializeServices(ClusterEntrypoint.java:356)
at org.apache.flink.runtime.entrypoint.ClusterEntrypoint.runCluster(ClusterEntrypoint.java:282)
at org.apache.flink.runtime.entrypoint.ClusterEntrypoint.lambda$startCluster$1(ClusterEntrypoint.java:232)
at org.apache.flink.runtime.security.contexts.NoOpSecurityContext.runSecured(NoOpSecurityContext.java:28)
at org.apache.flink.runtime.entrypoint.ClusterEntrypoint.startCluster(ClusterEntrypoint.java:229)
at org.apache.flink.runtime.entrypoint.ClusterEntrypoint.runClusterEntrypoint(ClusterEntrypoint.java:729)
at org.apache.flink.runtime.entrypoint.StandaloneSessionClusterEntrypoint.main(StandaloneSessionClusterEntrypoint.java:59)
My docker version is:
Client:
Cloud integration: v1.0.29
Version: 20.10.22
API version: 1.41
Go version: go1.18.9
Git commit: 3a2c30b
Built: Thu Dec 15 22:28:41 2022
OS/Arch: darwin/arm64
Context: default
Experimental: true
Why does the container not allow creating the required directory?
Looks like this was related to disk space issue. Running docker system prune cleared some space and the container is running nicely.

How do you mount the docker socket on Windows?

I'm trying to make an application work on Windows that's been developed only on Unices. It's all dockerized and it uses the traefik load balancer. The volumes for the docker for running traefik looks like this:
volumes:
- /var/run/docker.sock:/var/run/docker.sock:ro,delegated
- ${PWD}/load_balancer/traefik.toml:/etc/traefik/traefik.toml:ro,delegated
The first volume works fine on Mac or Linux, but does it on Windows? The application is failing (the load balancer is giving a 404) and it might be related to that volume. When I start the image, the socket looks like a socket:
/ # ls -laF /var/run/docker.sock
srw-rw---- 1 root root 0 Sep 2 11:04 /var/run/docker.sock=
Is this working? Any way to test it? What's the correct way of doing this?
Trying to figure this out, I tried replacing it with this:
volumes:
- //./pipe/docker_engine:/var/run/docker.sock
based on various articles and bug reports I found online. The docker image starts but it fails in the same way and now in the docker container it looks like a directory:
/ # ls -laF /var/run/docker.sock
total 4
drwxr-xr-x 2 root root 40 Sep 3 14:52 ./
drwxr-xr-x 1 root root 4096 Sep 3 14:57 ../
Following Marc ABOUCHACRA's answers, I tried:
volumes:
- type: npipe
source: ////./pipe/docker_engine
target: /var/run/docker.sock
consistency: delegated
but that also looks like a directory:
/ # ls -laF /var/run/docker.sock
total 4
drwxr-xr-x 2 root root 40 Sep 3 14:52 ./
drwxr-xr-x 1 root root 4096 Sep 3 14:57 ../
I also tried this:
volumes:
- npipe:////./pipe/docker_engine:/var/run/docker.sock:ro,delegated
but that fails with this error:
ERROR: Volume npipe:////./pipe/docker_engine:/var/run/docker.sock:ro,delegated has incorrect format, should be external:internal[:mode]
The whole docker-compose.yml section looks like this:
lb:
image: load-balancer
build: ${WORKSPACE}/go-home/load_balancer
ports:
- 80:80
- 443:443
links:
- wifi-ui-dev
- wifi-ui-prod
- portal
- wifi-api
env_file:
- .env
volumes:
- /var/run/docker.sock:/var/run/docker.sock:ro,delegated
- ${PWD}/load_balancer/traefik.toml:/etc/traefik/traefik.toml:ro,delegated
My question is specifically about running this docker image, which is a Linux, on a Windows host, running Docker for Windows. I understand that I can run it on a Linux host by installing Linux on another machine or a VM on the Windows machine, it's equivalent. Running Windows guests is not what I'm after either in case there's a way of exposing sockets from Windows to Windows only.
If you cannot nor want use network sockets, then you can use named pipes.
The syntax depends whether you run Linux or Windows containers and on the shell you use.
Linux containers
If you run Linux containers on a Windows machine, this seems to work using Powershell or bash:
docker run --rm -it -v "//var/run/docker.sock://var/run/docker.sock" image_with_docker docker version
Please note the extra / in front of /var/run/docker.sock, both for the source and destination volumes.
Windows containers
If you run Windows containers on a Windows machine, this seems to work using Powershell or bash:
docker run -v "//./pipe/docker_engine://./pipe/docker_engine" --rm -it image-with-docker docker version
Note that this works only in Powershell:
docker run -v "\\.\pipe\docker_engine:\\.\pipe\docker_engine" --rm -it image-with-docker docker version
Therefore, it's better to use the version with /.
Extra - docker-compose.yml
If you use a docker-compose.yaml file, this works with Windows containers.
version: '3.7'
services:
docker:
image: image-with-docker
command:
- docker
- version
volumes:
- type: npipe
source: \\.\pipe\docker_engine
target: \\.\pipe\docker_engine
With Linux containers, you can use the shortened form:
docker:
image: image-with-docker
command:
- docker
- version
volumes:
- //var/run/docker.sock://var/run/docker.sock
Extra - Kubernetes
If you are running Windows containers on a Windows node in Kubernetes, this seems to work:
apiVersion: v1
kind: Pod
spec:
containers:
- name: docker
image: image-with-docker
command:
- powershell
args:
- Start-Sleep
- "999999"
volumeMounts:
- mountPath: \\.\pipe\docker_engine
name: dockersock
volumes:
- name: dockersock
hostPath:
path: \\.\pipe\docker_engine
type: null
nodeSelector:
kubernetes.io/os: windows
In this case, beside using the \, please note the type: null in the definition of the dockersock volume: if you don't set it, it will not work.
Notes
Everything was tested on docker 19.03 and on Kubernetes 1.18.
Client:
Version: 19.03.3
API version: 1.40
Go version: go1.12.10
Git commit: 2355349d-
Built: 10/14/2019 16:41:26
OS/Arch: windows/amd64
Experimental: false
Server: Docker Engine - Community
Engine:
Version: 19.03.8
API version: 1.40 (minimum version 1.24)
Go version: go1.12.17
Git commit: afacb8b
Built: Wed Mar 11 01:37:20 2020
OS/Arch: windows/amd64
Experimental: false
If you encounter the following error on windows:
cannot create container for service portainer: Unrecognised volume spec: file '\.\pipe\docker_engine' cannot be mapped. Only directories can be mapped on this platform
ERROR: Encountered errors while bringing up the project.
Try adding an extra slash to it, resulting in following volumes section:
volumes:
- source: \\.\pipe\docker_engine\
target: \\.\pipe\docker_engine\
type: npipe
Tested with compose 3.7 and docker CE 19.03.12
Using short syntax with the type of the bind mount is not possible : npipe:////./pipe/docker_engine:/var/run/docker.sock:ro,delegated
You need to use the long syntax in your compose file :
volumes:
- type: npipe
source: ////./pipe/docker_engine
target: /var/run/docker.sock
consistency: delegated
You can find some documentation about the long syntax in the official documentation. This syntaxe is from v3.2
Also keep in mind what #lucas-ramage said about using windows container only when using npipe.
In 2022, on Windows 11, what worked for me is below volume configuration (Note the doube slash (//) on the host side of configruation. Not sure why docker_enginer variant does not work for me.
-v "//var/run/docker.sock:/var/run/docker.sock"
Per the Docker for Windows FAQ,
On Docker Desktop for Windows, clients can connect to the Docker Engine through a named pipe: npipe:////./pipe/docker_engine
See also this issue on GitHub,
The windows version of docker doesn't use unix socket (/var/run/docker.sock) but npipe (npipe:////./pipe/docker_engine). So you have either
to switch to linux container which runs docker in a full virtualized linux with unix socket
to pass the npipe instead of the unix socket to the container (windows container only)
to use a network socket (should work with linux and windows container)
However, since this is a Linux container, your options are either A) Run docker in a virtual machine (first choice above), or B) Use a network socket (the third choice).

Redis permission denied while opening dump.rdb

I am using official redis image with sidekiq on dockers.
Following are yml configurations for redis image:
redis:
build: .
dockerfile: Dockerfile-redis
ports:
- '6379:6379'
volumes:
- 'redis:/var/lib/redis'
sidekiq:
build: .
command: bundle exec sidekiq
links:
- db
- redis
volumes:
- .:/app
env_file:
- .env
Following is the code of my Dockerfile-redis:
FROM redis
COPY redis.conf /usr/local/etc/redis/redis.conf
CMD [ "redis-server", "/usr/local/etc/redis/redis.conf" ]
When I build the images everything works fine but after sometime docker-compose logs shows the following permission error:
redis_1 | 98:C 22 Jan 2019 18:40:10.098 # Failed opening the RDB file dump.rdb (in server root dir /var/lib/redis) for saving: Permission denied
redis_1 | 1:M 22 Jan 2019 18:40:10.203 # Background saving error
I have tried many solutions but I am still getting this error in logs. Everytime permission is denied for redis to open dump.rdb file. I have also followed this solution and done follwoing changes in my Dockerfile-redis to give root permission to redis
USER root
CMD chown -R root:root /var/lib/redis/
CMD chown 777 /var/lib/redis/
CMD chown 777 /var/lib/redis/dump.rdb
I have tried 755 for dir and 644 for dbfilename but it didn't worked for me. I also tried the above configurations of Dockerfile-redis with redis user but still I am getting the same permission denied error for opening dump.rdb file.
I don't know what I am doing wrong here. Please help me with this
After an hour of inactivity Redis will try to dump the memory db to disk.
Redis from the official redis image tries to write the .rdb file in the containers /data folder, which is rather unfortunate, as it is a root-owned folder and it is a non-persistent location too (data written there will disappear if your container/pod crashes).
So after an hour of inactivity, if you have run your redis container as a non-root user (e.g. docker run -u 1007 rather than default docker run -u 0), you will get a nicely detailed error msg in your log (see docker logs redis):
1:M 29 Jun 2019 21:11:22.014 * 1 changes in 3600 seconds. Saving...
1:M 29 Jun 2019 21:11:22.015 * Background saving started by pid 499
499:C 29 Jun 2019 21:11:22.015 # Failed opening the RDB file dump.rdb (in server root dir /data) for saving: Permission denied
1:M 29 Jun 2019 21:11:22.115 # Background saving error
So what you need to do is to map container's /data folder to an external location (where the non-root user, here: 1007, has write access), e.g:
docker run --rm -d --name redis -p 6379:6379 -u 1007 -v /tmp:/data redis
It seems that the official redis image is using an applicative user to run the redis-server and not root(which is a security best practice) regardless of USER definition - I extracted this from the image's entrypoint shell script:
# allow the container to be started with `--user`
if [ "$1" = 'redis-server' -a "$(id -u)" = '0' ]; then
find . \! -user redis -exec chown redis '{}' +
exec gosu redis "$0" "$#"
fi
when mounting a volume to a container, it is owned by the root user, it will override the default directory in the image's layer along with previous permissions.
It seems that the redis image intentions were not to expose the '/var/lib/redis' dir as a volume, instead they offer mounting to '/data/' for persistence:
If persistence is enabled, data is stored in the VOLUME /data, which can be used with --volumes-from some-volume-container or -v /docker/host/dir:/data (see docs.docker volumes).
For more about Redis Persistence, see http://redis.io/topics/persistence.
Start docker container from root, example:
redis:
build: .
dockerfile: Dockerfile-redis
user: root <-- REQUIRE
ports:
- '6379:6379'
volumes:
- 'redis:/var/lib/redis'
Please check the port in server. If it is open to the public then this issue is there which is very strange and difficult to diagnose.

Permission issues in nexus3 docker container

When I start nexus3 in a docker container I get the following error messages.
$ docker run --rm sonatype/nexus3:3.8.0
Warning: Cannot open log file: ../sonatype-work/nexus3/log/jvm.log
Warning: Forcing option -XX:LogFile=/tmp/jvm.log
Java HotSpot(TM) 64-Bit Server VM warning: Cannot open file ../sonatype-work/nexus3/log/jvm.log due to Permission denied
Unable to update instance pid: Unable to create directory /nexus-data/instances
/nexus-data/log/karaf.log (Permission denied)
Unable to update instance pid: Unable to create directory /nexus-data/instances
It indicates that there is a file permission issue.
I am using Red Hat Enterprise Linux 7.5 as host machine and the most recent docker version.
On another machine (ubuntu) it works fine.
The issue occurs in the persistent volume (/nexus-data). However, I do not mount a specific volume and let docker use a anonymous one.
If I compare the volumes on both machines I can see the following permissions:
For Red Hat, where it is not working is belongs to root.
$ docker run --rm sonatype/nexus3:3.8.0 ls -l /nexus-data
total 0
drwxr-xr-x. 2 root root 6 Mar 1 00:07 etc
drwxr-xr-x. 2 root root 6 Mar 1 00:07 log
drwxr-xr-x. 2 root root 6 Mar 1 00:07 tmp
On ubuntu, where it is working it belongs to nexus. Nexus is also the default user in the container.
$ docker run --rm sonatype/nexus3:3.8.0 ls -l /nexus-data
total 12
drwxr-xr-x 2 nexus nexus 4096 Mar 1 00:07 etc
drwxr-xr-x 2 nexus nexus 4096 Mar 1 00:07 log
drwxr-xr-x 2 nexus nexus 4096 Mar 1 00:07 tmp
Changing the user with the options -u is not an option.
I could solve it by deleting all local docker images: docker image prune -a
Afterwards it downloaded the image again and it worked.
This is strange because I also compared the fingerprints of the images and they were identical.
An example of docker-compose for Nexus :
version: "3"
services:
#Nexus
nexus:
image: sonatype/nexus3:3.39.0
expose:
- "8081"
- "8082"
- "8083"
ports:
# UI
- "8081:8081"
# repositories http
- "8082:8082"
- "8083:8083"
# repositories https
#- "8182:8182"
#- "8183:8183"
environment:
- VIRTUAL_PORT=8081
volumes:
- "./nexus/data/nexus-data:/nexus-data"
Setup the volume :
mkdir -p ./nexus/data/nexus-data
sudo chown -R 200 nexus/ # 200 because it's the UID of the nexus user inside the container
Start Nexus
sudo docker-compose up -d
hf
You should attribute correct right to the folder where the persistent volume is located.
chmod u+wxr -R <folder of /nexus-data volumes>
Be carefull, if you execute previous command, it would give write, read and execution right to all users. If you want to give more restricted right, you should modify the command.

Concourse Quickstart Docker Permissions Error

I'm trying to setup the Concourse CI locally by following the documentation. Everything goes great until I try to run a sample hello-world pipeline. The job results in this error...
runc create: exit status 1: container_linux.go:264: starting container process caused "process_linux.go:339: container init caused \"rootfs_linux.go:56: mounting \\\"/worker-state/3.8.0/assets/bin/init\\\" to rootfs \\\"/worker-state/volumes/live/a8d3b403-19e7-4f16-4a8a-40409a9b017f/volume/rootfs\\\" at \\\"/worker-state/volumes/live/a8d3b403-19e7-4f16-4a8a-40409a9b017f/volume/rootfs/tmp/garden-init\\\" caused \\\"open /worker-state/volumes/live/a8d3b403-19e7-4f16-4a8a-40409a9b017f/volume/rootfs/tmp/garden-init: permission denied\\\"\""
Looks like I'm getting a permissions error but I've double-checked that the container is running in privileged mode.
$ docker inspect --format='{{.HostConfig.Privileged}}' concourse_concourse_1
true
Docker Compose File
version: '3'
services:
concourse-db:
image: postgres
environment:
- POSTGRES_DB=concourse
- POSTGRES_PASSWORD=concourse_pass
- POSTGRES_USER=concourse_user
- PGDATA=/database
concourse:
image: concourse/concourse
command: quickstart
privileged: true
depends_on: [concourse-db]
ports: ["8080:8080"]
environment:
- CONCOURSE_POSTGRES_HOST=concourse-db
- CONCOURSE_POSTGRES_USER=concourse_user
- CONCOURSE_POSTGRES_PASSWORD=concourse_pass
- CONCOURSE_POSTGRES_DATABASE=concourse
- CONCOURSE_EXTERNAL_URL
- CONCOURSE_BASIC_AUTH_USERNAME
- CONCOURSE_BASIC_AUTH_PASSWORD
- CONCOURSE_NO_REALLY_I_DONT_WANT_ANY_AUTH=true
- CONCOURSE_WORKER_GARDEN_NETWORK
Pipeline
---
jobs:
- name: job-hello-world
public: true
plan:
- task: hello-world
config:
platform: linux
image_resource:
type: docker-image
source: {repository: busybox}
run:
path: echo
args: [hello world]
Concourse Version
$ curl http://192.168.99.100:8080/api/v1/info
{"version":"3.12.0","worker_version":"2.0"}
Other Versions
$ docker --version
Docker version 18.04.0-ce, build 3d479c0
$ docker-machine --version
docker-machine version 0.14.0, build 89b8332
$ docker-compose --version
docker-compose version 1.21.0, build unknown
$ system_profiler SPSoftwareDataType
Software:
System Software Overview:
System Version: macOS 10.13.1 (17B1003)
Kernel Version: Darwin 17.2.0
Boot Volume: OSX
While everything on the surface may look like it's up to date. It's important to note that docker-machine runs docker inside of VMs which can get stale if you're not updating them on a regular basis and Concourse needs kernel 3.19 or higher.
Running docker info can shed some light on the situation from Docker server's perspective.
What worked for me was...
$ docker-compose down
$ docker-machine upgrade
$ docker-compose up -d

Resources