Developing
As outlined in the main Decap README, Decap stores build logs and metadata in AWS S3 and DynamoDb. Follow the steps described there to create your AWS decap user, buckets, tables, keys, and policies.
Decap queries Github for Git branch and tag information on your projects. For this, you will need to create a Github app, which yields OAuth2 credentials for use in the Decap Kubernetes Secrets. Again, see the main Decap README for how to configure the secrets to use these Github credentials.
You can develop Decap without these AWS and Github configurations, but you cannot successfully interact with a deployed Decap without them.
Decap is a Go 1.5 application.
Install Go 1.5, which also installs the cross compilers.
Clone the repository, locating it properly in your Go workspace. Adjust the URL as necessary if you forked or are cloning over SSH.
$ cd $GOPATH/src
$ git clone https://github.com/ae6rt/decap.git github.com/ae6rt/decap
The Decap webapp is the main Kubernetes application that gets deployed into the cluster to execute builds.
$ cd web
Build the Decap OSX and Linux binaries
$ make
The OSX binary is useful for local development, and is configured via command options to override the normal in-container defaults.
The Linux binary is baked into the Docker container that would normally get deployed into the cluster as part of the decap replication controller.
You can stop short of building the binaries by executing tests only
$ make test
Package Decap in a Docker container
$ make container
This creates a container with the Decap webapp binary and its frontend UI app.
By default, the container is pushed to DockerHub account ae6rt. Change the account in the Makefile
DOCKER_USER := yourdockerhubusername
N.B. If you change the Dockerhub account name from ae6rt, you must also change its associated image for the decap replicationController in the file k8s-resources/decap.yaml in the next step on deploying the webapp into the cluster.
...
spec:
volumes:
-
name: "decap-credentials"
secret:
secretName: "decap-credentials"
containers:
-
image: "quay.io/coreos/etcd:v2.1.1"
args:
- "-listen-client-urls"
- "http://0.0.0.0:2379"
- "--advertise-client-urls"
- "http://127.0.0.1:2379"
name: "etcd"
resources:
limits:
cpu: "100m"
memory: "50Mi"
-
image: "ae6rt/decap:latest" # <<<<<<<<<<<<<<<<<<<<<<<<<<<
name: "decap"
...
$ make push
In the top level directory of the repository there is a script start-decap.sh
#!/bin/sh
set -ux
kubectl create -f k8s-resources/decap-namespaces.yaml
for i in decap decap-system; do
kubectl --namespace=$i create -f k8s-resources/decap-secrets.yaml
done
kubectl create -f k8s-resources/decap.yaml
The only file that needs editing here is k8s-resources/decap-secrets.yaml. This file needs to be updated to reference your Github OAuth2 credentials, and your AWS decap user access id and secret. Once that's done, deploy the application into the cluster
$ sh start-decap.sh
$ kubectl --namespace=decap-system get rc
CONTROLLER CONTAINER(S) IMAGE(S) SELECTOR REPLICAS
decap etcd quay.io/coreos/etcd:v2.1.1 name=decap 1
decap ae6rt/decap:latest
$ kubectl --namespace=decap-system get se
NAME LABELS SELECTOR IP(S) PORT(S)
decap <none> name=decap 10.247.249.222 9090/TCP
lockservice <none> name=decap 10.247.11.41 2379/TCP
$ kubectl --namespace=decap-system get pods
NAME READY STATUS RESTARTS AGE
decap-j9smp 2/2 Running 0 1h
$ kubectl --namespace=decap-system describe rc decap
Name: decap
Namespace: decap-system
Image(s): quay.io/coreos/etcd:v2.1.1,ae6rt/decap:latest
Selector: name=decap
Labels: name=decap
Replicas: 1 current / 1 desired
Pods Status: 1 Running / 0 Waiting / 0 Succeeded / 0 Failed
No events.
$ kubectl --namespace=decap-system describe pod decap-j9smp
Name: decap-j9smp
Namespace: decap-system
Image(s): quay.io/coreos/etcd:v2.1.1,ae6rt/decap:latest
Node: 10.245.1.3/10.245.1.3
Labels: name=decap
Status: Running
Reason:
Message:
IP: 10.246.1.11
Replication Controllers: decap (1/1 replicas created)
Containers:
etcd:
Image: quay.io/coreos/etcd:v2.1.1
Limits:
cpu: 100m
memory: 50Mi
State: Running
Started: Mon, 05 Oct 2015 05:39:18 -0700
Ready: True
Restart Count: 0
decap:
Image: ae6rt/decap:latest
Limits:
cpu: 100m
memory: 50Mi
State: Running
Started: Mon, 05 Oct 2015 05:39:29 -0700
Ready: True
Restart Count: 0
Conditions:
Type Status
Ready True
No events.
The build container is the container that the Decap webapp will launch to actually execute your builds.
From the top level of the repository, cd into build-container and make and push this container.
Again, modify the Dockerhub user as you did for the webapp container in the Makefile
# Change this to your DockerHub user when developing decap
DOCKER_USER := yourdockerhubusername
$ cd build-container
$ make push
You will most likely want to create another container with this container as a base, as you'll want tools and state baked into your build container that the base container lacks.
The build container has baked into it simple AWS tooling to push console logs and build artifacts to S3, and build metadata to DynamoDb. This tooling is Go app located in main.go in the build-container directory.