Details
-
Task
-
Resolution: Fixed
-
Normal
-
None
-
None
-
None
-
NDS Sprint 9
Description
Best effort prototype of using Jenkins for our Docker build/tag/push process. Explore running in cluster and out of cluster. What would we need to do to make this work for NDS Labs (ansible installs, provisioning build nodes, Docker in Docker, etc)
In order, from most-to-least ideal:
Outside of Kubernetes (Hosted elsewhere, outside of Nebula as container or installed service):
- strong authentication required
- explore non-Jenkins CI for this? Possibly Docker Hub?
Outside of Kuberenetes (On Nebula, as container or installed service):
- authentication (username/password will do)
- does not require external IP or exposure outside of nebula
Inside of the Cluster (Single Shared / Managed Instance)
- we host a single jenkins instance that we add jobs to on the user's behalf
- no exposure of jenkins interface to users
Internal (User-Managed Application):
- explore jenkins as a runnable NDS Labs spec
- must pass in docker socket... see
NDS-351for example - user manages jenkins themselves via web interface
- is the jenkins CLI accessible? do we need to expose this somehow? we could store it on the AppData volume
- no code modifications required
- will need to provide a tutorial for setting up simple Docker builds
- does not require external IP or exposure outside of nebula
- should we disallow user from marking this as "external"?
Internal (Per-User Single-Run Pod):
- this is essentially a much more complex version of
NDS-351 - Start jenkins pod, use API to add build job, execute build, and kill pod when build is complete (whether pass or fail)
- export a volume to save build job details / workspaces / artifacts externally
- is it trivial to know when the build is complete? can we use a livenessProbe for this?
- must prevent multiple simultaneous builds on the same project
- attempt to utilize isolated docker instance?