See the Table of Contents on the right to jump to a specific question.
Provided you have Docker installed, a quick start approach to using Concourse on a local machine can be achieved by pasting this line in the terminal:
wget https://concourse-ci.org/docker-compose.yml && docker-compose up -d
This pulls the latest version of Concourse and runs it on your local machine. Concourse will be running at localhost:8080. You can log in with the username/password as
Next, install Concourse's CLI component, fly, by downloading it from the web UI and target your local Concourse as the test user:
fly -t tutorial login -c http://localhost:8080 -u test -p test
From here, you can head to a Hello World tutorial to start learning how to put Concourse to work.
After running smoothly for a period of time, Concourse sometimes gives a 'max containers reached' error and stops working. What gives? Currently support's recommendation is to recreate the worker VM, is there a better solution?
The short answer is that recreating worker VMs is the fastest and easiest way to solve the problem and get back up and running. This bug has been solved in later releases (from v5.5.4 onward), so upgrading is key to a long term fix.
Why does Concourse do this?
Originally, Concourse could only garbage-collect containers that were tracked in the database. In some niche cases, it is possible for containers and/or volumes to be created on the worker, but the database (via the web node) assumes their creation has failed. If this occurs, these untracked containers can pile up on the worker and use resources, eventually leading to the 'max containers reached' error.
How did the team fix this in v5.5.4?
Concourse now garbage collects containers that aren't tracked in the database, cleaning up these orphaned containers before they can cause problems. See Issue #3600 for more details.
I am currently running a version of Concourse that is pre v6.0.0 and my database CPU is constantly under heavy load, what can I do to lower it if I cannot upgrade right away?
There were huge improvements with the scheduling algorithm that helped decrease database CPU within the v6.0.0 release, so the best method to solve DB load issues is to upgrade. However, if upgrading is not an option and the cause of the high database CPU is indeed due to the scheduling algorithm, there are two temporary workarounds.