I have a container that works on my local machine with:
docker run -d -v /sys/fs/cgroup:/sys/fs/cgroup:ro --cap-add SYS_ADMIN -p 80:80 -it foo:latest
How should I run this container within drone and be able to access port 80 from within a step?
Generally speaking, binding to port 80 inside a container does not require any special permissions or capabilities. Also note that when you declare a service container in Drone you do not need to bind to a host port, since all service containers are attached to the same network. So the following should work:
kind: pipeline
name: default
steps:
- name: curl
image: golang
commands:
- sleep 10 # give the web server time to initialize
- curl http://web:80
services:
- name: web
image: foo:latest
Thanks @bradrydzewski. The container I’m trying to run uses systemd internally, which is where the need for the cgroups and cap-add comes from.
Is there a way to get it running as a service within Drone? I basically need to run it and connect to its port so I can run some tests.
Edit: cap-app => cap-add
There is no way to set individual capabilities, however, you can enable privileged mode which enables all capabilities including sys_admin.
services:
- name: web
image: foo:latest
+ privileged: true
Excellent thanks. Is it necessary to also map the volumes like so?
services:
- name: web
image: foo:latest
privileged: true
volumes:
- name: cgroup
path: /sys/fs/cgroup:ro
volumes:
- name: cgroup
host:
path: /sys/fs/cgroup
When I try the above, I get no output from the web service. However, if I change it to:
services:
- name: web
image: foo:latest
privileged: true
volumes:
- name: cgroup
path: /sys/fs/cgroup
volumes:
- name: cgroup
host:
path: /sys/fs/cgroup
I do get output, but systemd within the container fails to start:
+ systemctl status
Failed to connect to bus: No such file or directory
I just tested the following yaml:
kind: pipeline
type: docker
name: default
steps:
- name: web
image: alpine
pull: if-not-exists
privileged: true
commands:
- ls -la /sys/
- ls -la /sys/fs
- ls -la /sys/fs/cgroup
volumes:
- name: cgroup
path: /sys/
volumes:
- name: cgroup
host:
path: /sys/
which I used to confirm the directories were mounted as expected:
$ drone exec --trusted
[web:0] + ls -la /sys/
[web:1] total 4
[web:2] dr-xr-xr-x 13 root root 0 May 25 01:15 .
[web:3] drwxr-xr-x 1 root root 4096 Jun 8 23:29 ..
[web:4] drwxr-xr-x 2 root root 0 May 25 01:16 block
[web:5] drwxr-xr-x 21 root root 0 May 25 01:15 bus
[web:6] drwxr-xr-x 41 root root 0 May 25 01:15 class
[web:7] drwxr-xr-x 4 root root 0 May 25 01:15 dev
[web:8] drwxr-xr-x 12 root root 0 May 25 01:15 devices
[web:9] drwxr-xr-x 6 root root 0 May 25 01:15 firmware
[web:10] drwxr-xr-x 9 root root 0 May 25 01:15 fs
[web:11] drwxr-xr-x 2 root root 0 Jun 8 23:29 hypervisor
[web:12] drwxr-xr-x 9 root root 0 May 25 01:15 kernel
[web:13] drwxr-xr-x 129 root root 0 May 25 01:16 module
[web:14] drwxr-xr-x 2 root root 0 Jun 8 23:29 power
[web:15] + ls -la /sys/fs
[web:16] total 0
[web:17] drwxr-xr-x 9 root root 0 May 25 01:15 .
[web:18] dr-xr-xr-x 13 root root 0 May 25 01:15 ..
[web:19] drwxr-xr-x 2 root root 0 Jun 8 23:29 9p
[web:20] dr-xr-xr-x 2 root root 0 Jun 8 23:29 bpf
[web:21] drwxr-xr-x 15 root root 300 May 25 01:15 cgroup
[web:22] drwxr-xr-x 4 root root 0 Jun 8 23:29 ext4
[web:23] drwxr-xr-x 3 root root 0 May 25 01:15 fuse
[web:24] dr-xr-xr-x 2 root root 0 May 25 01:15 pstore
[web:25] drwxr-xr-x 3 root root 0 Jun 8 23:29 xfs
[web:26] + ls -la /sys/fs/cgroup
[web:27] total 0
[web:28] drwxr-xr-x 15 root root 300 May 25 01:15 .
[web:29] drwxr-xr-x 9 root root 0 May 25 01:15 ..
[web:30] dr-xr-xr-x 21 root root 0 May 25 01:15 blkio
[web:31] dr-xr-xr-x 21 root root 0 May 25 01:15 cpu
[web:32] dr-xr-xr-x 21 root root 0 May 25 01:15 cpuacct
[web:33] dr-xr-xr-x 21 root root 0 May 25 01:15 cpuset
[web:34] dr-xr-xr-x 21 root root 0 May 25 01:15 devices
[web:35] dr-xr-xr-x 21 root root 0 May 25 01:15 freezer
[web:36] dr-xr-xr-x 21 root root 0 May 25 01:15 hugetlb
[web:37] dr-xr-xr-x 21 root root 0 May 25 01:15 memory
[web:38] dr-xr-xr-x 21 root root 0 May 25 01:15 net_cls
[web:39] dr-xr-xr-x 21 root root 0 May 25 01:15 net_prio
[web:40] dr-xr-xr-x 21 root root 0 May 25 01:15 perf_event
[web:41] dr-xr-xr-x 21 root root 0 May 25 01:15 pids
[web:42] dr-xr-xr-x 21 root root 0 May 25 01:15 systemd
So based on my testing it looks like Drone is mounting the volume as expected. I do not have any systemd experience and can therefore not provide any support for systemd error messages.
Thanks @bradrydzewski. Appreciate you taking the time to test it out and post the results. I’ll post back here for others if I manage to get it running.
I was able to get this working.
Here’s the solution for anyone else who comes across the problem:
kind: pipeline
type: docker
name: default
steps:
- name:
# important: do not add a commands section
# a commands section prevents systemd from starting
image: foo-systemd
# needs to run as a detached step
detach: true
# superset of --cap-add SYS_ADMIN
privileged: true
volumes:
- name: cgroup
path: /sys/fs/cgroup
volumes:
- name: cgroup
host:
# note:
# path: /sys/fs/cgroup:ro will not work
path: /sys/fs/cgroup