https://github.com/vito/lattice-concourse
scripts and stuff for running concourse on lattice
https://github.com/vito/lattice-concourse
Last synced: 3 months ago
JSON representation
scripts and stuff for running concourse on lattice
- Host: GitHub
- URL: https://github.com/vito/lattice-concourse
- Owner: vito
- Created: 2015-04-10T17:00:50.000Z (over 11 years ago)
- Default Branch: master
- Last Pushed: 2015-04-10T17:51:00.000Z (over 11 years ago)
- Last Synced: 2025-03-20T22:25:53.467Z (over 1 year ago)
- Language: Shell
- Size: 113 KB
- Stars: 2
- Watchers: 1
- Forks: 0
- Open Issues: 0
-
Metadata Files:
- Readme: README.md
Awesome Lists containing this project
README
# Concourse on Lattice
These two scripts will get you going from a regular old
[Lattice](https://github.com/cloudfoundry-incubator/lattice) deployment to
a running, scalable [Concourse](https://concourse-ci.org) cluster.
Have fun!
## usage
Grab [Lattice](https://github.com/cloudfoundry-incubator/lattice/releases),
deploy it somewhere (follow their docs), and target it.
Then, run:
```sh
./start-atc 'postgres://user:pass@your-progres-server.com:5432/atc'
./start-worker 'http://atc.your-lattice-ip.xip.io'
```
This will spin up a single, empty ATC server, and then one worker, which will
register with the ATC.
To populate the ATC with a [Concourse pipeline
config](https://concourse-ci.org/pipelines.html), download
[Fly](https://concourse-ci.org/fly-cli.html) from the ATC's web UI, and run
the following:
```sh
export ATC_URL='http://atc.your-lattice-ip.xip.io'
fly configure -c path/to/pipeline.yml
```
Or, just run [one-off
builds](https://concourse-ci.org/fly-cli.html#%28part._fly-execute%29) against
it.
## scaling up
Both the ATC and the workers can be scaled up and down. though it doesn't
really make sense to have any more than you have cells.
## caveats
* Concourse's build scheduling across workers is nowhere near as sophisticated
as Diego's, but is "good enough" to just throw on Lattice, given that most
builds are finite and don't have predetermined memory/disk limits.
* Currently the workers are publicly routable. This is bad.
* The PostgreSQL server must run externally. Once Diego does persistence/TCP
routing this will be easier.
* The workers have no memory/disk limits, and may tend to monopolize their
host cell.