Open frenata opened 6 years ago
The idea is that, when running a compilebox
API server, we only need to run build.sh
which will handle building the actual compilebox
Docker image and the API server image. Systems which will interact with the API server should be able to integrate both Dockerfiles
into their deployment setup (e.g. docker-compose.yml
).
build.sh
: will build the compilebox
docker image on the host and then build the compilebox
API server using the Dockerfile
(below).Dockerfile
: will build the docker image for the compilebox
API servernormally we can just run docker run
on our API server image, but since the running container will be using Docker, we want to make it use the Docker daemon on the host. We can do this by running,
λ docker run -v /var/run/docker.sock:/var/run/docker.sock -d --name server_container server_image
which links the docker daemon socket in the container with the one on the host. This allows the host to spin up a sibling container.
Note that we can also specify this runtime argument within docker-compose.yml
.
Dockerfile
vs. docker-compose.yml
for allowing container to use host Docker daemon? : VOLUME
in Dockerfile
specifies a point within the container to be mounted at build time whereas, the -volumes
properties in docker-compose.yml
specifies where to mount a volume on the host machine. Important to note that the -volumes
property in docker-compose.yml
is passed to docker run
at runtime. Also, we are allowed to use -volumes
without specifying a VOLUME
in the Dockerfile
.Dockerfile
in docker-compose.yml
build?: doesn't look like this is possible, so build.sh
will just be a convenience script for building both Dockerfiles
at the same time, but if a system is using docker-compose
, the docker-compose.yml
can just build each of the two Dockerfile
s without using the build.sh
.compilebox
Docker image inside container spinning it up as a sibling container or on host?Possibly relevant to your work: since the actual sandbox is unlikely to change much, I've pushed it to docker hub https://hub.docker.com/r/frenata/xaqt/ (also experimenting with the proposed name).
We'll presumably still want the Dockerfile in the repo somewhere so that we can change it, but it could be moved out of the base directory. And presumably when you compose the images, you can pull it directly.
I changed it so that https://hub.docker.com/r/frenata/xaqt-sandbox/ is set as the sandbox itself, so that we can use frenata/xaqt as the service target.
Once this is issue is resolved I'll make the appropriate changes to auto-build that target too.
FYI @connorwalsh , I had to do some major surgery on the Dockerfile since it suddenly stopped building. Security certs for the version of node being built got deprecated apparently.
@frenata, no worries! sorry for radio silence-- i'm getting back on this probably tomorrow
@frenata, no worries! sorry for radio silence-- i'm getting back on this probably tomorrow
It's cool @connorwalsh , I haven't exactly been spending a lot of time on this lately either. Hoping to get back to a bit soon though.
@frenata i was working on this previously but i am going to switch gears and refactor the library to use the Go Docker API since i think that is more valuable.
From #2 :