With the advent of per-user Docker, we've got a few different options open here.

We are not limited to only one build scheme, but the more we offer, the more work it will be to keep it all in repair / in-sync when we want to make changes.

I am personally still on the fence about whether it would be beneficial or detrimental to give the user access to the Docker CLI, so I have foregone that as a possible pro / con in the following scenarios.

Testing Docker on Jenkins

Upon first starting Jenkins, you will be asked to enter the admin password that has been printed to the Jenkins log file.

After entering this admin password, you will be prompted to set up an administrative user - you can skip this for now and continue as "admin", whose password was printed in the log.

Plugins

You will be asked if you want the recommended plugins or if you want to select your own - go ahead and select the recommended plugins and you should see them slowly install one by one.

You can install new plugins at any time by choosing "Manage Jenkins" from the dashboard and choosing to "Manage Plugins" from the menu.

Create a Job

Once Jenkins is ready, you will be dropped at the Dashboard with a "create new job" link in the center of the page.

1. Click this link and set up a new "Freestyle job" - name the new job whatever you would like and click "Ok"
2. Under Point this build job at the Git repository containing the Dockerfile you would like to build (for example, https://github.com/bodom0015/jenkins-experiment)

3. Scroll down and add a build step of "Execute shell":

   Code Block
   language bash
   docker build -t test .

4. Click Apply / Save

You should be dropped at the "Job Details" screen viewing your newly created job

Run a Build

On the "Job Details" screen, you will see a "Build Now" button on the left side. Click this button to perform a new build.

After a few seconds, you will see your new build status appear under the Build Progress queue.

Click the link to navigate to the "Build Details" screen, where you can view more details about a particular run of a build job.

Click the "Console Output" link on the left side to view the output of this build job.

If a build fails, you will likely need to view this output in order to fix the broken build.

Solution A: Per-User Docker Sidecar

Summary: Run a single-build Docker Pod on the user's behalf using their personal docker instance/socket

Example: See 

• ndslabs-docker

Pros:

• lightweight - no service(s) required to run when no jobs are building
• User cannot access the raw Docker socket used by Kubernetes

Cons:

• No tracking of build history, status, queues, etc

Result: Ideal and seemingly low-effort solution

Solution B: Per-User Docker +

...

Jenkins Spec

Summary: Allow user to run and manage their own Jenkins instance using their personal docker instance/socketSee 

Example: 

• jenkins.json

Pros:

• highly customizable build system
• rich plugin support for different languages, frameworks, and workflows
• could easily be enabled - assuming 

  Jira
  server JIRA serverId b14d4ad9-eb00-3a94-88ac-a843fb6fa1ca key NDS-439

• User cannot access the raw Docker socket used by Kubernetes

Cons:

• CI is very complex - we don't want to be in the business of supporting / fixing Jenkins problems
• we would need to enforce auth, although the 2.7.1 build of jenkins used for the dind tag makes you set up an admin user on first-run
• requires user to manually set up the build in order to integrate back into NDS Labs

Result: I feel like this should be a service that we offer on NDS Labs, but not necessarily force it on users or manage it for them 

Solution C: Centralized Internal

...

Jenkins

Summary: Run a centralized jenkins instance within Kubernetes to run Docker builds on all users' behalfSee 

Example: 

• service.yaml

...

• controller.yaml

Pros:

• complexity is hidden from the user
• no authentication is needed unless we wish to expose this to the public internet (we may need to tunnel in)
• User cannot access the raw Docker socket used by Kubernetes
  

Cons:

• would likely force tight coupling between our API and Jenkins'

Result: Tight Coupling => Not Ideal 

Solution D: Exo-Kubernetes

...

Jenkins

Summary: Spin up a raw VM on Nebula and run a jenkins instance on it outside of KubernetesSee 

Example: 

• run-ci.sh

Pros:

• complexity is hidden from the user
• no authentication is needed unless we wish to expose this to the public internet (we may need to tunnel in)
• User cannot access the raw Docker socket used by Kubernetes

Cons:

• would likely force tight coupling between our API and Jenkins'

Result: Tight Coupling => Not Ideal

Solution E: Exo-Nebula CI

Summary: Use some CI server that does not reside on Nebula

...

• DockerHub
• TravisCI
• CircleCI
• etc

Example: See 

• bodom0015/ndslabs-web-ui

Pros:

• we support this workflow right now

Cons:

• requires user to manually set up one of the following in order to integrate back into NDS Labs
  • automated build
  • Docker CLI (for manual pushes)

Result: No reason why we can't support this one, but it would be beneficial for us to offer alternatives