jasonewall/traepis repository overview

This tool is intended for feature testing in a QA/staging environment. Say you have multiple feature branches you want to test before merging into your mainstream deployment repo. Traepis lets you point to a docker image tag, assign it an ID (i.e.: a ticket number from your issue tracker) and it will automatically route traffic to a specific URL for that build.

Possible production use: Needing to replicate alternate builds of your app to different domains (or routing paths, whatever your ingress controller supports).

⁠Prerequisites

• A functioning ingress controller in your Kubernetes cluster.
• ... A Kubernetes cluster.

⁠Environment Variables

• KUBERNETES_OBJECT_CONFIG_FILE_DIR - location of the config map containing all your Kubernetes object templates (See: https://github.com/jasonewall/traepis/blob/alpha1/.minikube/config/2.configmap.yaml⁠)
• KUBERNETES_DEFAULT_NAMESPACE - if namespace is not defined by the objects in your config templates - which namespace do you want to default to?
• ROOT_APPLICATION_DOMAIN - e.g.: qa.yourapp.com
• APPLICATION_DOCKER_REPOSITORY - e.g.: jasonewall/traepis, yourcompany/yourdockerrepo
• TRAEPIS_INSTANCE_ID - Unique identifier for this instance of traepis. Can just be traepis if only running one instance, but if running multiple instance - allow traepis to tag created k8s objects (with labels) so traepis will only will manage objects created by this instance.

⁠Required volumes

You need to mount templated config files into the traepis container so traepis knows which objects to create per build. Recommend at least a deployment, service, and ingress. See link above again for templating examples.

⁠Template variables available

build.id (Field in UI) build.image_tag (Field in UI) build.domain - generated off of ROOT_APPLICATION_DOMAIN and build.id build.image - generated by APPLICATION_DOCKER_REPOSITORY and build.image_tag