- Make sure
helmis installed, and
helm versionreturns the correct server.
- Add the Brigade repo:
helm repo add brigade https://brigadecore.github.io/charts
- Install Brigade:
helm install brigade-server brigade/brigade(or
helm install brigade/brigade --name brigade-serverif using Helm 2)
- Create a Brigade project:
brig project create
At this point, you have a running Brigade service. You can use
helm get brigade-server and other Helm tools to examine your running Brigade server.
By default, Brigade is not configured with a load balancer service for incoming requests. Rather, cluster ingress comes in the form of one or more Gateways that provide configurable services, usually in tandem with ingress resources.
Brigade Github App Gateway with External IP
Let’s take the example of enabling the GitHub App Gateway.
By default, the Brigade Github App gateway chart defines the associated service type as
ClusterIP, which is only accessible within the Kubernetes cluster. If we wish to set up the gateway with an externally-visible IP of type
LoadBalancer, we would upgrade our
brigade-server release like so:
$ helm upgrade brigade-server brigade/brigade --set brigade-github-app.enabled=true --set brigade-github-app.service.type=LoadBalancer
We’d then locate the external IP as follows:
$ kubectl get svc brigade-server-brigade-github-app NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE brigade-server-brigade-github-app LoadBalancer 10.0.110.59 184.108.40.206 80:30758/TCP 45d
brigade-server-brigade-github-app is just the name of the Helm release (
EXTERNAL-IP field is the IP address that external services, such as GitHub in this example, will use to trigger actions.
There will be more configuration needed for the
brigade-github-app sub-chart for GitHub events to reach a Brigade project.
See more at GitHub App Gateway.
Note that this is just one way of configuring Brigade to receive inbound connections. Brigade itself does not care how traffic is routed to it. Those with operational knowledge of Kubernetes may wish to use another method of ingress routing. See the Ingress doc for more information.
Notes for Minikube
You can run Brigade on Minikube for easy testing and development. Minikube provides built-in support for caching and sharing files during builds. However, there are a few things that are much harder to do when running locally:
- Listening for GitHub webhooks requires you to route inbound traffic from the internet to your Minikube cluster. We do not recommend doing this unless you really understand what you are doing.
- Other inbound services may also be limited by the same restriction.
Notes for Azure Container Services (AKS)
Brigade is well-tested on AKS Kubernetes. We recommend using at least Kubernetes 1.6.
- It is recommended to use a Service with type LoadBalancer on AKS, which will generate an Azure load balancer for you.
- For caching and storage, we recommend creating an Azure Storage instance and
creating a Persistent Volume and Storage Class that use the
AzureFiledriver. (For an example, see the
Azure File Setupsection in the storage document.)
- You can use Azure Container Registry for private images, provided that you add the ACR instance to the same Resource Group that AKS belongs to.
- ACR’s webhooks can be used to trigger events, as they follow the DockerHub webhook format.
- When configuring webhooks, it is recommended that you map a domain (via Azure’s DNS service or another DNS service) to your Load Balancer IP. GitHub and other webhook services seem to work better with DNS names than with IP addresses.