Signed-off-by: Erik Hollensbe <email@example.com>
|1 year ago|
|boot||1 year ago|
|box-builds||1 year ago|
|client||1 year ago|
|cmd||1 year ago|
|config||1 year ago|
|doc||1 year ago|
|docker-compose.d||1 year ago|
|lib||1 year ago|
|runner||1 year ago|
|sd||1 year ago|
|service||1 year ago|
|test||1 year ago|
|vendor||1 year ago|
|.gitignore||1 year ago|
|.golangci.yml||2 years ago|
|.wwhrd.yml||1 year ago|
|LICENSE||1 year ago|
|Makefile||1 year ago|
|README.md||1 year ago|
|docker-compose.yml||1 year ago|
|go.mod||1 year ago|
|go.sum||1 year ago|
|oauth.yml.example||1 year ago|
|task.yml||1 year ago|
|tinyci-runner.yml.example||1 year ago|
|tinyci.yml||2 years ago|
This is the TinyCI 0.3.0 framework. It has a lot of useful things you may be interested in, but it is nowhere near complete at this point in time.
tinyCI's framework is about 95% GRPC and JWT with a dash of NATS. It has a full RBAC layer and some support for multi-site federation / untrusted API access.
TinyCI's framework is not really a high performance framework. The intent is not to make something ultra fast, but flexible enough to fit into most environments as CI systems typically don't beat up anything other than the runners themselves. As a result, you may see trades in here that I have tried to note below.
Docker and docker-compose are required prerequisites for playing around.
will install my toolchain (which requires sudo to install at one point, but
only then) and boot a docker-compose instance with the CI stack, runner, and
all dependencies. Jaeger is used for local tracing, and prometheus is tied to
consul so all services are automatically discovered and scraped.
You will want to copy the
too. After doing all that and starting the stack,
docker-compose exec tinyci bash
will get you near a place where you can play around.
go install -v ./...
will be necessary to install the
tinyci-dev binary which can do some data
faking and queue filling; otherwise the
tinyci admin command should already
be available for playing around a bit.
make test outside of the containerized environment also works, and validates
In most cases tinyCI is optimized for portability. All services are bundled
into a single binary. Currently, the
tinyci boot command boots all of them at once.
This is intentional at this stage to keep it simple, but as you can see if you
trawl through the
cmd directory's imports you will see the capability for an
easy split-out. The idea here was that you can bundle multiple services onto
hosts depending on need. Do a lot of logging? Fan out logging only, etc.
It does not use DNS for service lookup at all, it instead uses the consul API
directly. This incurs a ~100ns hit on RTT in local testing with a lot of
genuine advantages, a large one being that DNS isn't necessary to use. You can
find this work in the
lib directory is a large portion of the framework; inside you will
find work around linux-style capabilities to evoke an RBAC-like system with JWT
and all the GRPC glue to support that; there's also a tiny smidgeon of work
service directory are the actual services. They are short applications
used to talk to and provide resources.
client contains custom client wrappers
for the services, intended for external consumption.
Most services have a simple protocol and are easy to replace to support other
forms of resource management.
authsvc writes to disk, for example; it should
be trivial to make it target S3 with a functionality replacement and WITHOUT
compromising the rest of the system.
authsvcis a oauth-compatible service suitable for linking oauth services to your user database, through
usersvcis the user store. Uses (hopefully) not terrible crypto practices.
reposvcis a service for managing github repositories
queuesvcis still new, and a method for communicating with runners (also new, see
logsvcis a graph-oriented logging system that leverages facebook's
entto log to postgresql.
assetsvcis a CI log management system currently, but is intended to manage all stored assets.
I hope you like it, or if nothing else, find it entertaining. I'll be building on this more.
Erik Hollensbe firstname.lastname@example.org
MIT, (c) 2020