You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently to use portainer and build images remotely, users have to run their own instance of the framework locally, which is a bit cumbersome. The idea here is to slightly generalise the framework scheduler to be able to run both as an ephemeral tool (as it currently does) and also as a long running HTTP API.
The API would be compatible with the Docker Remote API endpoint POST /build.
Rationale
Currently the Dockerfile format used with portainer is the basic Docker format, with extra command. In recent docker versions, commands that are unknown to the build system will cause the build to fail, whereas they were previously ignored. We'd like to move towards unifying the experience with docker and portainer such that building with portainer is just an opt-in choice to run a build remotely instead of locally... rather than an entirely separate build system.
Example
The scheduler could be invoked with a command such as;
Once the scheduler is running, the standard docker CLI tools can be used to execute a build on the Mesos cluster.
docker -H portainer-scheduler.local:1234 build .
Output
Due to the simple data structures used in the remote API response, the portainer build scheduler can stream useful build status information back to the user using the docker CLI tools. The output might look something like this.
Sending build context to Docker daemon 3.584 kB
---> Scheduling build for tarnfeld/portainer:tag
---> Launching build on node-1234.cluster.internal with cpus:1, mem:512
Step 0 : FROM things
---> Running in d37d756f6e55
---> de1d48805de2
Step 1 : RUN apt-get update
---> Running in d37d756f6e55
---> de1d48805de2
Step 2 : RUN apt-get install ruby
---> Running in d37d756f6e55
---> de1d48805de2
Squashing image de1d48805de2 into a single layer
---> fe928da99e0a0
Tagging image fe928da99e0a0
---> my-registry.internal/tarnfeld/portainer:tag
Pushing image
...
The text was updated successfully, but these errors were encountered:
Overview
Currently to use portainer and build images remotely, users have to run their own instance of the framework locally, which is a bit cumbersome. The idea here is to slightly generalise the framework scheduler to be able to run both as an ephemeral tool (as it currently does) and also as a long running HTTP API.
The API would be compatible with the Docker Remote API endpoint
POST /build
.Rationale
Currently the
Dockerfile
format used with portainer is the basic Docker format, with extra command. In recent docker versions, commands that are unknown to the build system will cause the build to fail, whereas they were previously ignored. We'd like to move towards unifying the experience with docker and portainer such that building with portainer is just an opt-in choice to run a build remotely instead of locally... rather than an entirely separate build system.Example
The scheduler could be invoked with a command such as;
Once the scheduler is running, the standard docker CLI tools can be used to execute a build on the Mesos cluster.
Output
Due to the simple data structures used in the remote API response, the portainer build scheduler can stream useful build status information back to the user using the docker CLI tools. The output might look something like this.
The text was updated successfully, but these errors were encountered: