TARZÁN CODE
Now when you push code to the master branch, your image will automatically be rebuilt and pushed to Docker Hub. Or ( tarzan is set as a ENTRYPOINT in the Docker image): docker run -d -p 80:3000 \ If you like, you can also choose a secret (to prevent spamming of your webhook endpoint) and pass it to tarzan with the -secret option: tarzan -secret mySecret -p 80 On Github, click on “Settings” (the bottom-most element) in the right hand panel, then click on “Webhooks & Services”.Ĭlick the “Add webhook” button, verify your identity, and paste the IP address of your tarzan server at the /build endpoint in the URL box. v /var/run/docker.sock:/var/run/docker.sock \ Tarzan is also available to run as a Docker container (built, of course, using tarzan): docker run -d -p 80:3000 \ 80 will do fine if you plan on using this box only for tarzan. Make sure that the port you’re exposing on is accessible to the outside world. Install tarzan on the worker box and start it. Getting Startedįirst you should get a virtual private server of the appropriate size (a small server at, say, Digital Ocean will probably do nicely to start - they have a built-in Docker image as well).Īlternatively, if you just want to try tarzan out the “fast and dirty” way, you could use a proxy tunneling service such as the excellent ngrok and run it locally on your computer.
TARZÁN INSTALL
On Debian based systems, the following should work: sudo apt-get install -y git-coreĪs mentioned in the next section, tarzan is also available to run in a Docker container. Make sure you have docker and git binaries installed as well. Or install the (64bit Linux) binary directly using something like: curl | sudo tee /usr/local/bin/tarzan 2>&1>/dev/null chmod +x /usr/local/bin/tarzan You can install tarzan using either: go get /nathanleclaire/tarzan However, it could still be turn out to be a useful tool for automating Docker image re-builds and deploys. I say it is “naive” because it doesn’t attempt to do anything particularly clever (largely it shells out to docker commands) and is inherently meant to run on a single host (though this may change in the future). Tarzan is a naive implementation of such an automated build robot, written in Go. Therefore, it would be highly preferable to have an automated build robot which runs builds using the Docker cache. This makes Automated Builds look very unattractive for real production deployments. This means that even if you only changed one character in one line of source code, you will most likely have to pull down anywhere from 80 megabytes to a gigabyte or more of Docker image layers. When end users go to docker pull the image built using an Automated Build, they always get new layers even if they have pulled that same image before.Because the layers are completely new, Docker’s build robot pushes all new layers when it pushes the built image back to Docker Hub, slowing the Automated Build down even more (the familiar "image layer already exists, skipping" message is nowhere to be found).This ends up in an Automated Build process which could take ten minutes or more (for an operation which would take seconds locally) and does not use the Docker build cache (one of the best, most oft-cited features of docker build) at all.Because Docker’s build robot runs Automated Builds using the -no-cache option (the infrastructure costs of not doing so would be prohibitive), all of the image layers are created from scratch each time.However, there is a big problem incorporating Automated Builds in a real-life workflow in their current form. They allow you to automatically re-create your Docker images on source control push, and they allow other people to find the Dockerfile used to create your image to inspect and play around with before pulling, running, or modifying it. Automated Builds are one of the best features of the Docker Hub.