Inspiration

This project inspired me because of the problems I've faced with conventional CI/CD platforms like Jenkins, Bamboo, Teamcity.

  1. Agents were java/other applications running on a VM with no isolation between the build and the agent, sometimes causing hard to reproduce issues.
  2. Agent machines needed to be customized with differing capabilities (SDKs, versions, libraries, resources like cpu/mem, etc). This is complex, usually requiring your OPS team to setup, maintain.
  3. Binding builds to specific agents which have the required capabilities is wasteful, as you must wait for an idle agent with your requirements before your build would run.
  4. An agent is no longer "untouched" after the first build it runs. State changes between builds can cause unexpected failures or worse, false-successes (unless the machine was reprovisioned after every build, not an easy or cheap thing to do).
  5. Build agents require licensing which can be very expensive (in addition to the hardware).
  6. Build agents are often underutilized. Either idle, or running builds that have many steps and can take awhile, while not fully utilizing all CPU/Mem/IO/Network resources.
  7. There are several online options like Travis, Circle, but those services have other constraints such as available memory, maximum concurrency, and other things that you may not be able to necessarily do (like, the ability to access private resources on the company network). Also, you can take advantage of scaling the cloud VMs (such as in AWS) that host your Swarm to save even more money.

What it does

SwarmCI is CI extension as well as (future) a stand-alone CI/CD platform. You can use SwarmCI to extend an existing CI system (Bamboo, TeamCity, Jenkins, etc) with a few steps:

  1. Setup a Docker Swarm.
  2. Converting existing build tasks, stages, and jobs to a single .swarmci file.
  3. Configure a single task in your build to run a single command to delegate work to your Docker Swarm:

python -m swarmci

How we built it

SwarmCI was built to be simple and lightweight above all else. The .swarmci file outlines the stages, jobs, and tasks. Stages are run sequentially, jobs within a stage are run in parallel using multiple threads, each of which creates a container in the Swarm, with an infinite sleep loop entrypoint. The tasks within the job are then run using docker exec against the running container, with stdout being captured and returned to the user.

The future plans are to:

  1. User Interface (running in the Swarm)
  2. Workers (running in the Swarm)
  3. A persistence layer (read database)

With the above components, setup and running jobs is even simpler, as you don't need to install any python packages, instead you are running swarmCI as services within the Docker Swarm. Running jobs consists of making an HTTP API call to kick things off.

Challenges we ran into

Initially, the system looked complicated, with many moving parts. As I continued to play with Docker 1.12 swarm features, it became clear that we could simplify everything down to 1 component, and in the future, it would be as few as 3 components.

Accomplishments that we're proud of

SwarmCI solves many of the problems found in conventional CI/CD platforms.

  1. Build tasks are run within a docker container, the image of which provided by the user, completely isolated from build agent and the rest of the host. In addition, the starting state of a build does not change between builds, as containers aren't reused.
  2. The Docker image in which tasks are run within is provided by the user, thus, it can be completely customized. Never wait for an idle agent that has your requirements, or for the OPS team to configure an agent with new requirements for you.
  3. Resource waste is decreased because builds run on the Swarm. As long as a node on the Swarm has the available CPU/Memory requirements for your build, your build runs. Scale your Swarm down to keep waste to a minimum, and scale it up as demand requires it.
  4. With the SwarmCI as a extension, you can get isolated, distributed, parallel build tasks without sacrificing the use of additional build agents from your existing platform.

What we learned

Mainly, that Docker is really awesome!

What's next for SwarmCI

The stand-alone CI/CD platform will require:

  • User-Interface
  • Build Manager(s) on the Swarm
  • Data Persistence Backend

Built With

Share this project:

Updates