Add support for additional packages

[blop]

Would be nice to support the setup of additional (apk) packages through a environment variable.
This way we can add build capabilities without forking the docker image.

Something like :
X_ADDITIONAL_PACKAGES : "nodejs nodejs-npm"

That would run at startup :
apk add --update nodejs nodejs-npm

This way bamboo can build stuff with nodejs, or with any deployment specific dependencies ;-)

[cptactionhank]

Interesting idea, i'll look into that 👍

[pixel-shock]

That not only interesting, that's a must have! Sorry, but how should bamboo do "it's thing" without packages like "composer" and other stuff? Or run php unit tests without installed php?

Currently the whole docker image is useless for my work. I'm working with bamboo since years, but within this image I can't use it in any way 😠

[cguentherTUChemnitz]

Another method to abstract the build dependencies is to do the building inside a docker container. I am running this successfully for a while. Therefore i armed the bamboo image with the docker package:
cguentherTUChemnitz@8a2b2b6

For a more generalized usage, the group number of the docker group should be configurable. In the linked commit i used my docker group number of my hostsystem.

The way i do (and prefer to do) CI:

• run bamboo as a docker container
  • mount /var/run/docker.sock:/var/run/docker.sock into the bamboo container --> this enables the container to start sibling containers on the host-system
  • the docker service in bamboo needs to be runned with the same group-id as on the host
• provide every ci-enabled project a dockerfile, which builds a build-container including the build dependencies for the project
• bamboo needs only access to the repo and the docker dependency, building and running the project as a docker container in a "local" worker.

--> Summarizing you don't need build dependency management in bamboo, when you use the docker in docker approach for CI. This is very handy, especially when you place your CI build environment information directly into your project as an Dockerfile.

So i would vote for an bamboo image from @cptactionhank (which is better supported as my fork), providing the docker runtime, with configurable docker group ID. If you wish, i can explain further the docker in docker approach for CI.

best,
Christian

[blop]

The problem when you run bamboo plan with a "remote" docker daemon, is that you can't use simple mounted volumes to pass files in/out of the sub docker container as they are not present on the machine/container that run the docker daemon itself.

It'd be nice if the bamboo/bamboo.agent containers could offer a "sub" docker daemon inside their own container, besides the bamboo processes. This way the docker daemon would be able to mount path from the working directories of the bamboo/bamboo.agent.

So I suggest to create docker containers inside the bamboo containers, not as siblings.
Also, this avoid the security issue where you have to mount the docker socket from the host.

This can be done, as docker inside another docker is supported.
See https://hub.docker.com/_/docker/

[cguentherTUChemnitz]

Yep, there are several pros and cons between docker in docker and docker as siblings. You mentioned https://hub.docker.com/_/docker/, where also https://jpetazzo.github.io/2015/09/03/do-not-use-docker-in-docker-for-ci/ is linked.

My decision is based on:

cons of docker in docker:

• a lot of possible data-corruption possible problems as outlined by jpetazzo
• additional performance penalty: > IMPORTANT: this image defaults to --storage-driver=vfs, which will be very slow and inefficient (but is the only driver which is guaranteed to work regardless of your underlying filesystem)

pro docker in docker:

• bamboo stuff can be mounted directly into the build container

neutral:

• i assume the security is bad for both options
  • docker in docker needs the privileged flag
  • docker as siblings needs for a specific group direct access to the host docker system

So i decided to use the sibling way for a machine, where the CI administrator also has access to the host docker system. Than you are right, i had to retrieve the host-mounted path of the bamboo build folder, to be able to mount it into the container. As long as this is possible for the CI-admin i would prefere the sibling way.

[luishdez]

I've found the very same problem with my first test. Besides the support to install deps on creating the container.

Is that it switch to USER daemon:daemon that doesn't have any privileges to apk :( so you can't even installed on build process.

bash-4.4$ apk add php
ERROR: Unable to lock database: Permission denied
ERROR: Failed to open apk database: Permission denied

bash-4.4$ su -
su: must be suid to work properly

😔

[isoos]

Here is my config that allowed to install docker inside the image:

FROM cptactionhank/atlassian-bamboo:6.3.1
ARG DOCKER_GID
USER root
RUN apk add --no-cache git-lfs shadow docker

RUN groupmod -g ${DOCKER_GID} docker && \
    usermod -aG docker daemon
USER daemon

EXPOSE 8085 54663
VOLUME ["/var/atlassian/bamboo","/opt/atlassian/bamboo/logs"]
WORKDIR /var/atlassian/bamboo
ENTRYPOINT ["/docker-entrypoint.sh"]
CMD ["/opt/atlassian/bamboo/bin/start-bamboo.sh", "-fg"]

Also, the docker-compose needs the following instead of the image key:

    build:
      context: .
      dockerfile: bamboo-dockerfile
      args:
        DOCKER_GID: 116

116 was the GID on my server.

Many thanks to @cguentherTUChemnitz for providing the base work for this.

[wethinkagile]

I wanted to install npm on my docker, but if exec-ing into it and doing a simple apt-get update it fails.

Someone has better idea? Maybe provide npm in runner image?

apt-get update
E: Could not open lock file /var/lib/apt/lists/lock - open (13: Permission denied)
E: Unable to lock directory /var/lib/apt/lists/
E: Could not open lock file /var/lib/dpkg/lock - open (13: Permission denied)
E: Unable to lock the administration directory (/var/lib/dpkg/), are you root?
daemon@bamboo-server-vpcfn:/var/atlassian/bamboo$ su root
su: must be run from a terminal

[cptactionhank]

You are not logged in as root, use the --user flag with docker exec to login as root to be able to run apt-get update

[ariel123]

How do you run the command with --user flag? I get permission denied
docker exec --user root -it {container-name}

[aubreyk8]

Thanks @cptactionhank it worked for me. This is how i ran it

docker exec -it --user=root bamboo /bin/bash