Skip to main content

Step 5. Deploy first application

Now that McDougals has a test cluster, they are ready to deploy an application.

App repository

First, they should create an applications repository. They could create everything in the mcdougals-edgecell repo, but the provider Edgecell has readonly access to that repo. It should really only contain the information that the provider needs to see, and they only need to see what things the customer needs to field. They do not need to know what applications the customer is deploying to those fieldings.

So, they create a new repo called mcdougals-apps and add it to the workspace. The app repo is not required but recommended.

Helm repository

Edgecell uses Helm charts to deploy containers, even for single node placements. Helm charts do not need to be intimidating. We provide a tool that can create a Helm chart for a single container application. There is also a tool for converting Docker compose to Helm.

Helm charts need to be stored in a registry. There are public registries. GitEdge provides a Helm chart repository for you if you do not have one already.

We create an explicit declaration of the Helm repo will use, even if it is the same Gitedge server we are using for our app repo.

apiVersion: edgecell.io/v1
kind: HelmRegistry
metadata:
name: mcdashboard
namespace: mcdougals.com
spec:
interval: 1m
url: https://mcdougals.gitedge.io/api/v1/packages/placements/helm/

Helm Release

The user will create a release object in the app repo to instruct what placements should have what applications.

apiVersion: edgecell.io/v1
kind: HelmRelease
metadata:
name: mcdashboard-pilot
namespace: mcdougals.com
uuid:
labels:
annotations:
spec:
interval: 5m
selector:
matchNames:
- mcdougals.com/pilot01
chart:
spec:
chart: mcdashboard
version: '>=1.0.0'
sourceRef:
kind: HelmRegistry
name: mcdashboard
namespace: mcdougals.com
interval: 1m
values:
replicaCount: 2

Let's highlight some key items here.

spec/chart/spec defines what Helm chart to release. It points to the Helm Registry object that we created above.

spec/selector/matchNames defines which placements should have this application. In this case, we are giving the specific name of a single placement, the pilot placement defined in step 2.

Usually an edge release will go to multiple placements using the matchLabels selector. The selectors follow the patterns used in Kuberenetes.

When you commit this release to main branch, GitEdge will automatically deploy the app to the target cluster(s).