Docker Desktop / Extend CLI usability with container and registration command

[edsiper]

Calyptia CLI command is useful when already installed and the user already knows its own API keys. But we aim to simplify the process for users to try out Calyptia Core in Docker Desktop.

I am working on building a Docker Desktop extension for Calyptia Core (feel free to take over this) and I found some missing pieces to automate the process, and make it easier. What is missing to simplify the onboarding process ?

• Calyptia CLI command container image. Our public docker hub organization does not have the CLI tool exposed
• CLI should support a core-register option that redirects the user in the browser to the core.calyptia.com domain. This command must check if Core is already installed or not.
• Once the user authenticates, the CLI waits for the credentials set in the cloud. So it can auto-install Core in the local Kubernetes cluster defined by Docker Desktop

With those components in place the workflow in Docker Desktop should be:

• Docker Desktop: add Calyptia Core extension

• the extension runs our container and automates registration, e.g:

  docker run calyptia/calyptia-cli core-register

• the user register or re-login, the CLI receives the credentials to install Core

• upon successful installation:

  • Docker Desktop opens a browser Tab with Core UI

[nicolasparada]

I don't know if that is something I would put inside the CLI. Not in the Dockerfile of the CLI.

I would create a new Dockerfile dedicated to the docker-desktop extension and put the CLI inside and all the necesary stuff for it to work. It might not need anything new in the CLI itself.

[edsiper]

NOTE: just confirmed with @niedbalski that Docker Hub is not necessary since the CLI is already published in a container in the google register, we might just need the option to register and auto-install core in the environment.

if is not clear the workflow suggested is, happy to join a call to explain it further.

[patrick-stephens]

Initially I'll focus on providing everything to make an extension and run it with our containers. Separately we can also update the workflows as necessary.

This looks like a good basis as follows along the same lines of what we want: https://github.com/loft-sh/vcluster-dd-extension

[patrick-stephens]

I've been pulling together an initial POC but it is not complete yet: https://github.com/patrick-stephens/core-docker-desktop-extension

I do not think we should be coming up with another way of using our CLI or another tool/wrapper - this is both more work to implement and explodes the complexity matrix for test & support. Instead we should be using the normal CLI approach a user currently would follow but integrate this with Docker Desktop. To that end I propose we follow the approach vCluster does for their extension: they also have a CLI tool and run it on a local K8S cluster so this is identical to what we want I believe.

Now, on to the details:

• My POC currently tests for local K8S cluster being running and triggers an error message if not.
• It then runs the local binary to talk to the cluster, although this is not completed yet.
• It triggers the load of the cloud.calyptia.com webpage to get the token.

The approach vCluster uses is to ship a binary for each supported Docker Desktop target as part of the extension and use this directly from the host. This would then mirror the same usage as we currently support and test (apart from the new targets for Windows & MacOS).

Note we are tied to supporting the targets that Docker Desktop does as well, and that includes each version of Docker Desktop so this is something to consider.

As part of this work I would really caution on waiting for this all to stabilise:

• Developing Docker Desktop extensions is frankly a large time sink at the moment: the biggest issue is the lack of complete documentation, the documentation is just missing a lot of the important details so you have to delve into other people's code and experiment to figure it out.
• The actual development environment also is immature: it is hard to test things as you can never really guarantee the latest version is actually being used: hot reload sometimes works for the UI but seems to be dependent on exactly what is changed so the only real cycle I've got to work is install new version, quit Docker Desktop and restart Docker Desktop - then it takes a while for the K8S cluster to stabilise each time. Debugging is a whole separate problem, even getting logs out is difficult particularly if things fail before they start.
• With it being beta there is no guarantee it will not be completely broken by the next release, e.g. Mirantis push an update for Kubecon (as we want to do for our headline products) that breaks all our usage.

[edsiper]

thanks @patrick-stephens for the initial work on this and for sharing the concerns.

I understand this ecosystem is new, but for business reasons we need to make it happen. we need to bring the experience of "1-2 clicks" to deploy Core in Docker Desktop without the need to copy/paste tokens or commands, just using the mouse.

@nicolasparada can you confirm if you will be looking at the auth part ? IIRC @niedbalski mention something about bringing device tokens back to life.

[nicolasparada]

I already have a library for auth0 device code flow. I did it recently trying new ideas for the CLI. I'll share the code 👍

[edsiper]

@nicolasparada thanks.

@niedbalski is this booked as a deliverable from backend side ? happy to discuss more how to make it happen.

[niedbalski]

@nicolasparada thanks.

@niedbalski is this booked as a deliverable from backend side ? happy to discuss more how to make it happen.

Yes, we will work on this.

[edsiper]

@niedbalski for the project, we have a deadline of October 11, I want to check if it "will" be on track. If there any resource-challenge pls let me know to think on a plan B.

[niedbalski]

OK, I have transferred this issue to this repository. We'll be tracking the progress here. From our latest sync; I will put the micromanager hat on here. Recap on Docker Desktop Extension.

• [x] @patrick-stephens to implement open a browser UI to the Core UI based on the core_instance label UUID. WIP
• [x] @patrick-stephens to tidy up the code and do a CI/release workflow. WIP
• [x] @nicolasparada to work on integrating the auth0 desktop workflow. Needs some research on integrating the official SDK.

@edsiper AFAIU we have rudimentary but functional extension by now. We miss 2 important features still; 1) (WIP) Full auth workflow 2) (WIP) Automatic detection of a running instance and open up a browser. Also, we might need some art/UI improvement for the final delivery.

[patrick-stephens]

I'll look at getting the ball moving on marketplace approval as well, not sure the specifics of this yet and how easy it is to update

[edsiper]

thanks @niedbalski and @patrick-stephens

we will take care of the UI and CSS next week so we can focus on functional pieces first.

note: please setup your emails in the repo:

commit bcde354dbe6924c24ab756feeb1ba4cc3e2145c3 (HEAD -> main, origin/main, origin/HEAD)
Author: Pat <patrick.j.k.stephens@gmail.com>
Date:   Thu Oct 6 15:21:30 2022 +0100

    initial commit (#1)

    Signed-off-by: Patrick Stephens <pat@calyptia.com>

commit ef31658934845edd164dc7e4f42271b207916de5
Author: Jorge Niedbalski <niedbalski@gmail.com>
Date:   Wed Oct 5 17:16:46 2022 +0200

    Initial commit

[patrick-stephens]

Looks like it defaulted to my gmail for PRs in this repo so changed that now.

We should now have the following:

1. Start and detect K8S local cluster present.
2. If local K8S present, attempt to retrieve core instance UUID.
3. If no local core instance, provide the create new core instance page. This then goes to 2 once complete.
4. CI to create the containers.

This should handle various use cases including things like uninstalling or upgrading Docker Desktop.

Note no auto-launching of browsers yet - repainting currently means they repeatedly launch under various conditions.

[patrick-stephens]

This is complete now.