docker-archive / compose-cli Goto Github PK
View Code? Open in Web Editor NEWEasily run your Compose application to the cloud with compose-cli
License: Apache License 2.0
Easily run your Compose application to the cloud with compose-cli
License: Apache License 2.0
Take code from /docker/spiky to fetch hub login (if available) and send it with deployment info to allow hub private images in ACI.
Same for ACR registries (supporting tokens set by az acr login
).
Since there is no Desktop on Linux, we must document how users should install the new CLI
example : container Create() invokes Run()
ACI allows CPU / mem limitations. ATM we have hardcoded these limits when sending requests to ACI, we need to set flags to docker run
(--cpu, --memory, from the existing run flags) and transfer the user reqs to ACI, if specified.
currently the new CLI only has context ls
/ context create
command.
e2e test is using directly the old CLI in order to switch context, we must update e2e to run docker context use
on the new CLI
docker run
/ docker rm
command should output the container id that is created / deleted.
That should be used in e2e tests to execute a user flow
when running docker run nginx -p 80:80
, subsequent docker ps
should display a PORTS column with the ACI public IP & port where we can connect to the deployed app.
(Code can be taken from /docker/spiky)
By default, windows firewall does not allow any .exe to open ports, which the azure login process does to interact with the browser. Once the user clicks "allow" this does not happen anymore, but we should use Desktop to configure properly the windows firwall and allow the aci backend binary to execute without warning. (Desktop already has/had some similar code to allow smb port for filesharing)
$ ./bin/docker context create test1 toto
$ ./bin/docker context ls
NAME TYPE DESCRIPTION DOCKER ENPOINT KUBERNETES ENDPOINT ORCHESTRATOR
default * docker Current DOCKER_HOST based configuration unix:///var/run/docker.sock https://kubernetes.docker.internal:6443 (default) swarm
test1 toto
We must check the type and allow only types known by existing backends, or docker ("empty" type)
Docker Desktop must start the docker cli on a predefined named pipe. The SDK must connect by default on this npipe on win, if no specific socket is provided by the user.
SDK will not start the daemon if not available
$ ./bin/docker context use test1
test1
$ ./bin/docker context rm test1
test1
$ ./bin/docker context ls
exit status 1
the classic CLI allows context rm -f
, this switches to the default context before rm
Currently the spike changes the list of commands based on the context. if a user tries to use old commands that are not supported with aci/ecs, we return a generic error message :
$ docker-cli --context aci swarm init
docker: 'swarm' is not a docker command.
See 'docker --help'
We need to change this message to make it very explicit the command is not available because of the context switch, and it only exists in the "old" non-cloud context (and non-d2).
docker context create aci aci
has flags for subscriptionID, resourcegroup & location. We need to also allow interactive creation like in /docker/spiky, and let the user select the resource group from a proposed list
We need some events system similar to what moby engine has
currently the new CLI only has context ls / context create command.
e2e test is using directly the old CLI in order to remove context, we must update e2e to run docker context rm
on the new CLI
allow docker exec mycontainer "ls -al"
As defined here
If possible generate doc along with the generated nodejs SDK
External tools must be able to fetch information when docker context is switched to a non-docker daemon context (there is no more daemon API)
we must provide a way for external tools to access container functionality :
The cli already has a serve
command starting the grpc server.
We must package and ship the SDK for node js at least, and make it available for users
The help for --name
includes the randomly generated name.
$ ./bin/docker run --help
...
--name string Assign a name to the container (default "crazy-allen")
The existing CLI just shows:
$ docker run --help
...
--name string Assign a name to the container
*
./bin/docker context ls:\nCommand stdout:\nunexpected end of JSON input\n\nstderr:\n\nerror:\nexit status 1
)e2e tests are currently using the old cli to list context and check which is the default one, we meust update e2e to use the new CLI for this
We need to have consistent container IDs that allow to match output of docker ps
with docker logs
, docker exec
and docker inspect
.
This must work for single containers and also compose stack containers.
Single containers are fine, the container id is either generated or provided when the container is created first.
Compose stack : we need a way to identify both the compose project (mapped to a container group in ACI, also used for compose down
and possibly other compose commands, logs...) and the container ID. A naming convention : container id = composeProjectName_service_name
seems to work fine, it makes things easy to process technically, and also makes things easy to understand for a user when they do docker ps
, like with local compose containers
Scope
Implement data capture for just the number of 'run' events which is stored in a way that Docker Desktop could pick up.
This should aggregate over a 24 hour period and be written to a file that Desktop can pick up.
Goal
prove data capture from CLI and 'pick up' from Desktop
Background
We cannot capture data in the Docker Desktop proxy as the proxy would need to have full knowledge of all the flags. Instead this must be done in the cli. As this will therefore be open source it will need to default to off and have a standard, user auditable way of collecting the metrics.
The current suggestion is to have a common metrics collection interface in cli that links into the cobra commands. The backend for this interface could be:
A simple file backend that the Docker Desktop service reads the data from.
Separate Windows and Mac backends that forward the command usage to the Docker Desktop APIs. What backend to use should be configurable.
Previous suggestion was to use prometheus with local file storage to gather the metrics. Docker Desktop can periodically read and clear this.
define a way to share the SDK with our users : how do they download it, and use it in nodejs project.
At least nodejs, this is the target for VSCode
Currently we're using azure az
CLI client ID, and calls to azure will be associated with the az
command line.
MS must provide us a new client ID that will be specific to docker CLI, we'll need to update the id associated with login.
Currently we have an ACI command to fetch logs from a container.
ACI provides an API to specify a tail option to fetch a specified number of lines in the logs.
To follow logs, there is no streaming API, the az
command line polls logs and rewrites the ouput every 2 secs.
--follow
option to attach to logs--tail
option to tail logsCurrently, in order to allow service name resolution within a compose stack, once the compose containers have been started in ACI, we docker exec
inside one of the containers to write service names in /etc/hosts.
This requires containers to allow /bin/sh execution, and is done after all containers are running.
We should replace this docker exec
by adding a side car container to the compose stack, the side car doing nothing but writing service names to /etc/hosts.
the ps
implementation will need to filter out the side car containers so that they are not visible to users
Desktop packaging needs to be updated to fetch this new CLI in addition to the moby one.
Desktop docker
links (or PATH on windows) must point to this new CLI, and not to the moby one.
To ensure delegation works well, we will need to adjust how the shell out is performed (2 binaries in the same folder, with different binary names, or same names in different folders... )
Desktop packaging needs to be updated to fetch this new CLI in addition to the classic one.
Desktop docker PATH must point to this new CLI, and not to the classic one.
To ensure delegation works well, we will need to adjust how the shell out is performed (2 binaries in the same folder, with different binary names, or same names in different folders... )
What's called cli.proto today is actually just an API that returns contexts, we will rename it to context.proto
To be discussed : make binaries available through github release, automate github release on tag creation.
We'll need to have binaries for mac/linux/windows, mac/windows will be shipped through Desktop
Scope:
Capture the number of times the user has changed context and the contexts they have had 'in focus'.
Background
Overall background document: https://docs.google.com/document/d/1lzOtnyQnHyfwc3FI8jpCdi-VcprP_IQehWN7fHf_JNI/edit?ts=5eb3e676
The goal is to homogenize the build process through the devs' environments and make bumping process smoother.
At the moment we only allow run without specifying a command in the cmdline
Allow docker run ubuntu echo foo
Scope
Count the CLI commands used by a user by context and store them for desktop to access
Background
https://docs.google.com/document/d/1lzOtnyQnHyfwc3FI8jpCdi-VcprP_IQehWN7fHf_JNI/edit?ts=5eb3e676
the docker context azure-login
command from /docker/spiky must be moved to this repo.
Scope
Capture CLI flags by each command & by context
Background
https://docs.google.com/document/d/1lzOtnyQnHyfwc3FI8jpCdi-VcprP_IQehWN7fHf_JNI/edit?ts=5eb3e676
Follow up of https://github.com/docker/api/issues/63 :
GH release is created automatically & binaries for mac, win & unix are uploaded, we need to automate the release changelog (issues & PR for example, like https://github.com/depcheck/depcheck/releases) and checksums for binaries
Docker Desktop must start the docker cli on a predefined unix socket. The SDK must connect by default on this socket on mac, if no specific socket is provided by the user.
SDK will not start the daemon if not available
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.