Urbit: publish an official docker image

[s-ol]

this should ease setup for a lot of people.
There are existing Dockerfiles based on ubuntu and alpine here on github, but they are not maintained actively.
Seeing that docker is already used for builds here, wouldn't it make sense to embrace it and publish a docker image as well?

[matildepark]

Is using a docker image easier than running a single static binary? It seems like there would be more steps involved.

—
~haddef-sigwen
http://urbit.org

On Nov 11, 2019, at 12:28 PM, sol [e-mail] wrote:

this should ease setup for a lot of people.
There are existing Dockerfiles based on ubuntu and alpine here on github, but they are not maintained actively.
Seeing that docker is already used for builds here, wouldn't it make sense to embrace it and publish a docker image as well?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

[ohAitch]

I thought the single static binary had issues with pills and terminfo and
so on? but yeah docker's track record for filesystem reliability is not the
best, and having to explicitly mount the directory for your pier and open
ports and such would be extra configuration

On Mon, Nov 11, 2019 at 09:34, Matilde Park [e-mail]
wrote:

Is using a docker image easier than running a single static binary? It
seems like there would be more steps involved.

—
~haddef-sigwen
http://urbit.org

On Nov 11, 2019, at 12:28 PM, sol [e-mail] wrote:

this should ease setup for a lot of people.
There are existing Dockerfiles based on ubuntu and alpine here on
github, but they are not maintained actively.
Seeing that docker is already used for builds here, wouldn't it make
sense to embrace it and publish a docker image as well?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/urbit/urbit/issues/1934?email_source=notifications&email_token=AAOFPBQNC3HSPAAVADSEC4DQTGJSTA5CNFSM4JLYRFLKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEDXRLSA#issuecomment-552539592,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAOFPBWBHV7E7FSPN7LMSQDQTGJSTANCNFSM4JLYRFLA
.

[s-ol]

@matildepark for someone not using docker, sure. But the point would not be to replace the single static binary, but to provide a docker image for users which would prefer to host it this way.
There are services for deploying docker images directly, and some (like me) may prefer to run services containerized for ease of setup, maintenance etc.

@ohAitch exposing ports and mounting volumes are implicit in using docker images, any docker user would be used to that. The Dockerfile can specify the mounting point, so that the pier will be kept persistant separately from the container fs itself, which also makes mounting it to the host fs more straightforward. Of course the relevant options should be documented in a section of the setup manual.

[galenwp]

I'm pretty sure we have an image that's been used a bit for orchestration stuff. @brendanhay — thoughts on this?

[brendanhay]

The repo contains a image build script and associated Nix expression which are analogous to a Dockerfile. I've just pushed the result of that expression for the v0.9.2 tag to tloncorp on Docker Hub.

@galenwp - There should really be copy/instructions etc. on the Docker Hub landing page if want to advertise this, otherwise people risk losing their keys or data (ie. the ephemeral docker volume is discarded).

[jtobin]

There should really be copy/instructions etc. on the Docker Hub landing page if want to advertise this

Yeah I'll leave this open until things have been appropriately "officialized."

[eamsden]

Hi all,

I've been approved for a grant to try to make this happen.
https://grants.urbit.org/proposals/626138244-docker-image-for-cloud-container-orchestration

I'm creating an alternate nix dockerTools.buildImage build that will have "smart" loading from a volume:

• If the volume mount contains a .key file, it will boot a ship with that key.
• If the volume mount contains a pier, it will start the ship from that pier
• If the volume mount contains an (empty) .comet file, it will boot a comet.

Key and comet files in particular will be removed once the ship is booted. In this way, we make it easy to boot and continue running a ship in a container. Because the pier will be in a volume mount, the pier will be readily accessible if someone wants to remake their container with an upgraded version of the Urbit docker or to exit docker for e.g. local hosting.

Additionally, I am going to be producing documentation for this docker including cloud deployments. This documentation should be pushed to Docker Hub as well.

@brendanhay, since it sounds like you set up the tloncorp docker hub organization, would you be able to assist me with getting GitHub CI secrets set up so that release CI can push the latest image?

4256 is the PR where progress can be tracked.

[ohAitch]

Is this going to be based on https://hub.docker.com/r/asssaf/urbit?

[eamsden]

@ohAitch

Is this going to be based on https://hub.docker.com/r/asssaf/urbit?

No, I don't plan to derive from that image or base the design off of it. The image implementation is mostly done already. It is being built by nix (like the present one in this repository). It won't require any scripts or other interaction, making it suitable as a more-or-less one-click deploy on container hosting services, without needing any custom scripting.