shipcat

A standardisation tool and security layer on top of kubernetes to config manage microservices. Developers write manifests:

name: webapp
image: clux/webapp-rs
version: 0.2.0
env:
  DATABASE_URL: IN_VAULT
resources:
  requests:
    cpu: 100m
    memory: 100Mi
  limits:
    cpu: 300m
    memory: 300Mi
replicaCount: 2
health:
  uri: /health
httpPort: 8000
regions:
- minikube
metadata:
  team: Doves
  repo: https://github.com/clux/webapp-rs

and shipcat creates a 2 replica kubernetes deployment for this sample webapp, with a health check to ensure smooth upgrades. Contacts will be slack notified on upgrades.

Secrets are managed by Vault and resolved by shipcat pre-merge, and pre-upgrade.

Documentation

Browse the API documentation, or the setup guides available at:

• Introduction to shipcat
• Shipcat Definitions
• Setup for operations
• Building
• Clusters & Regions
• Extending shipcat
• Templates
• Vault
• Error handling
• Nautical terminology

Components

Shipcat is made up of three main components:

• shipcat_definitions - allowed syntax in our kube clusters - manifest.yml + shipcat.conf
• shipcat - the pipeline cli and validator useable by developers and CI
• raftcat - an kubernetes api/watcher that reads the shipcatmanifests custom resource

Integrations

While shipcat mainly deals with kubernetes, there are extensive and optional integrations with:

• Vault
• Kong
• StatusCake
• Slack

and some minor convenience integrations from common technologies like: Grafana, CircleCI, Quay.io, logz.io, Sentry, New Relic

CLI installation

• Mac/Linux users can install from the releases page
• Users with rust installed can use git pull && cargo build
• Babylon employees can brew install shipcat or brew update && brew upgrade shipcat via the internal brew tap

See the building guide, for setting up auto-complete, and being able to use from outside a manifests repo.

CLI Usage

Define your manifest.yml file in a manifests repo, make sure shipcat validate passes.

You either need to have a ~/.kube/config whose current-context is set to the shipcat region you wish to validate, or pass the shipcat region in explicitly with -r region.

If you have vault read credentials (a VAULT_TOKEN evar, or a ~/.vault-token file) you can validate secret existence and generate the completed manifest (values):

shipcat validate webapp --secrets

# Generate completed manifest (what's passed to your chart)
shipcat values webapp -s

If you have helm installed you can generate the helm template via the associated helm chart:

# Pass completed manifest to helm template
shipcat template webapp

License

Apache 2.0 licensed. See LICENSE for details.