In order to have the pipeline perform isolated deployments of services, we need access to a centralized repo of packaged helm charts managed in operations/deployment-charts. The current thinking is to have them hosted at https://releases.wikimedia.org/charts/.
Description
Description
Details
Details
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | None | T170453 FY2017/18 Program 6: Streamlined Service delivery | |||
| Invalid | None | T170480 FY2017/18 Program 6 - Outcome 2: Developers are able to develop and test their applications through a unified pipeline towards production deployment. | |||
| Invalid | None | T170481 FY2017/18 Program 6 - Outcome 2 - Objective 2: Set up a continuous integration and deployment pipeline | |||
| Resolved | None | T157469 Mathoid CI Container Build | |||
| Resolved | • dduvall | T183165 Verify functionality of the 'production' image in the context of an isolated k8s deployment | |||
| Resolved | • dduvall | T188935 modify service-pipeline to include helm install/helm test | |||
| Resolved | • dduvall | T191327 Come up with a decent method of declaring helm chart path/version in service repo | |||
| Resolved | • dduvall | T191821 Host packaged helm charts at https://releases.wikimedia.org/charts |
Event Timeline
Comment Actions
Change 425105 had a related patch set uploaded (by Dduvall; owner: Dduvall):
[operations/puppet@production] ci: Host helm charts at integration.wikimedia.org/charts
Comment Actions
Do we really want this on integration.wm.o? Or is this only serving them from there for integration purposes? Just seems a little odd if this is the canonical location.
Comment Actions
That all depends how we are going to deploy services to Kubernetes in the future. If the deployment is driven by CI (Jenkins or whatever), we can tie the deployment to integration.wikimedia.org. Else we would need another place, maybe the deployments servers?
Then I am not quite sure what operations/deployment-charts is going to be for :]
Comment Actions
Well ideally developers can use the same sets of charts, that's the main reason I thought of it as odd. docker-registry.wm.o seems nicer?
Comment Actions
IMHO, all deployment charts should reside in the same repository / on the same (sub)domain, regardless of whether they are for prod, CI or development use. The different use cases can be namespaced / separated by URL paths. From that perspective, integration.wm.o seems less than ideal.
Comment Actions
Change 425105 abandoned by Dduvall:
ci: Host helm charts at integration.wikimedia.org/charts
Reason:
Hosting at integration.wikimedia.org was deemed inappropriate as charts will have production and possible third-party applications. I'll write another patch for hosting at releases.wikimedia.org/charts.
Comment Actions
Change 425870 had a related patch set uploaded (by Dduvall; owner: Dduvall):
[operations/puppet@production] Host deployment charts at releases.wikimedia.org/charts
Comment Actions
Change 425870 merged by Dzahn:
[operations/puppet@production] Host deployment charts at releases.wikimedia.org/charts
Comment Actions
Oh! That's great. Now I can do the following locally on my minikube instance
Add and update the repo
$ helm repo add wmf https://releases.wikimedia.org/charts/ "wmf" has been added to your repositories $ helm repo update Hang tight while we grab the latest from your chart repositories... ...Skip local chart repository ...Successfully got an update from the "wmf" chart repository
Create the mathoid namespace (this is a bug of the chart, we should default to the "default" namespace instead of the "mathoid" namespace)
$ kubectl create ns mathoidAnd just install mathoid.
$ helm install wmf/mathoid --set main_app.version=build-39 NAME: mean-numbat LAST DEPLOYED: Fri Apr 13 12:12:48 2018 NAMESPACE: default STATUS: DEPLOYED RESOURCES: ==> v1/ConfigMap NAME DATA AGE mean-numbat-metrics-config 1 1s config-mean-numbat 1 1s ==> v1/Service NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE mathoid-mean-numbat NodePort 10.107.255.215 <none> 10044:30001/TCP 1s ==> v1beta1/Deployment NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE mathoid-mean-numbat 1 1 1 0 1s ==> v1/NetworkPolicy NAME POD-SELECTOR AGE mathoid-mean-numbat app=mathoid,release=mean-numbat 1s ==> v1/Secret NAME TYPE DATA AGE mathoid-mean-numbat-secret-config Opaque 0 1s
List/view the status of releases
$ helm list NAME REVISION UPDATED STATUS CHART NAMESPACE mean-numbat 1 Fri Apr 13 12:12:48 2018 DEPLOYED mathoid-0.0.2 default $ helm status mean-numbat LAST DEPLOYED: Fri Apr 13 12:12:48 2018 NAMESPACE: default STATUS: DEPLOYED RESOURCES: ==> v1beta1/Deployment NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE mathoid-mean-numbat 1 1 1 1 5m ==> v1/NetworkPolicy NAME POD-SELECTOR AGE mathoid-mean-numbat app=mathoid,release=mean-numbat 5m ==> v1/Secret NAME TYPE DATA AGE mathoid-mean-numbat-secret-config Opaque 0 5m ==> v1/ConfigMap NAME DATA AGE mean-numbat-metrics-config 1 5m config-mean-numbat 1 5m ==> v1/Service NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE mathoid-mean-numbat NodePort 10.107.255.215 <none> 10044:30001/TCP 5m
And finally just use the service
$ curl http://192.168.99.100:30001/_info {"name":"mathoid","version":"0.7.1","description":"Render TeX to SVG and MathML using MathJax. Based on svgtex.","home":"https://github.com/wikimedia/mathoid"}
@Dzahn Thanks!