Run gemstash in a docker container

[artemave]

I put up a little repo that sets it up. Let me know if you want to take ownership or to make it a part of this project.

[smellsblue]

I've never used Docker, but that's pretty cool! Is there a standard way to distribute Docker containers? I had heard of Discourse publishing as a Docker container, and it looks like it is a special repo for that: https://github.com/discourse/discourse_docker

I'm open to pulling it into Gemstash officially somehow (maybe as a plugin gem?), but I'd like to get thoughts from @pcarranza and @indirect too :-)

[artemave]

Is there a standard way to distribute Docker containers?

Images are push into Docker Hub. For example, this is an image built from my repository: https://hub.docker.com/r/artemave/gemstash/

And then docker pulls it in automatically when you create, run, etc. a container from artemave/gemstash image.

[pcarranza]

Way too late reply.

Hey, thanks a lot!

I think that the main question here would be. Is this generation automated in any way or it requires manual intervention to maintain it?

In a nutshell, I love the idea, I'm not sure I have cycles free to maintain it, so the more automated, the better.

[artemave]

We can put the contents of my repo in a folder in gemstash (let us call it docker). Then we can tell travis to build and push to docker hub after every successful master build.

If sounds good, I can make a pr.

[smellsblue]

Should it be after a new gem version is released instead? Master branch isn't intended to be deployed. There have been times when if you had deployed master, your Gemstash server might have had problems. For example, we have changed migrations rather than add new ones. This is fine if you just use the released gems, but not so much if you are using different phases of master branch.

Also we have a stable branch for 1.0... is there a way for different versions of the container to exist...? Could you keep a 1.0.0 container, upgrade it to 1.0.1 but not 1.1.0? (Is this even desirable?)

How do you set up authorization keys for the Gemstash container instance if you want to push private gems? (If you aren't using a container, you would run the gemstash authorize command)

Will or should the docker container support different database options? (If you aren't using a container, you can run gemstash setup to point to a database other than a SQLite database)

[pcarranza]

Really interesting questions, @smellsblue

I'm not sure adding the configuration to push any version as a docker file because of what @smellsblue said, not every version is releasable. Some are plain broken or require some level of migration.

I think that the release of these docker images should be more linked to the release versions (1.0.pre... 1.0.0, etc) than the builds.

Regarding the configurations, we have a configuration file, and there is probably a way of setting this up, same thing with the authorizations.

Probably what is missing here is adding some docs to explain how do I use this image and how do I run gemstash setup or authorize to change how the server is configured.

After than, is there a way of triggering a build from a different repo? maybe some form of API on travis/github to trigger the build of the docker image?

[artemave]

I spiked "docker setup as part of gemstash repository", but abandoned it eventually. In short, travis-ci isn't great for building pipelines.

[artemave]

@smellsblue I addressed your points re configuration and authorization: https://github.com/artemave/gemstash-docker

[artemave]

I agree, building only stable images is the right thing to do. As it stands, my current repo gets the latest gemstash gem from rubygems when it is building.

So, if a new image is built every time the gem is released then we're good. Docker hub has build triggers just for that.

If bundler were to take the ownership (or fork) of my repo, then you can incorporate build trigger into your release pipeline.

Alternatively, I can simply give you the link to post to trigger the build.

[rjocoleman]

I think the "Automated Builds" feature on Docker Hub is going to fit nicely here.

In a nutshell on pushes to master Docker Hub consumes the GitHub webhook, a build is created and an image published. It's configurable but usually master lives in the docker latest tag and all git tagged releases can have their own tagged images too. e.g. $ docker pull bundler/gemstash:1.0.1 would be a thing. README.md gets mirrored over to the docker hub page too. It'd live at https://hub.docker.com/r/bundler/gemstash.

For users this makes deployment via Docker very simple: docker run bundler/gemstash:1.0.1 (with a couple of other arguments to specify environment variables, exposed ports and persistence data volume)

I suggest a couple of changes to the artemave/gemstash image though, since I think the primary use case of Gemstash via Docker will be production deployment:

• Include database adapter dependencies so that postgres et al are usable out of the box. For postgres his requires both the pg gem and the deps for native extensions.

• Some method to get a custom config file in (this could be mitigated by ENV in the gemstash config yaml in #86). I think dropping this in the container as ~/.gemstash/config.yml is best.

• Add EXPOSE, ENV (if appropriate) and VOLUME so these are obvious.

• Right now data isn't persisted outside of the container so when it's restarted you'll be starting from scratch (bad news for config, sqlite and private gems). How to do this should be documented.

• Use both ENTRYPOINT and CMD to create a simplier interface like docker exec -it gemstash_server and docker exec -it gemstash_server authorize (ENTRYPOINT has more details on this).

  ENTRYPOINT ["gemstash"]
  CMD ["start", "--no-daemonize"]
  

I'm happy to build on @artemave's work to make the docker images production ready and add any automated build tooling and the relevant docs here... if there's interest in this as a "feature".

[rjocoleman]

I've made a first pass at this, with a view to use automated builds. I'm putting it into production here first (private gemserver on the internet) so that I can make sure it's performing as expected before creating a PR and working through the automation with a maintainer.

[jalberto]

Hi!

Is there any progress about this?

[itskingori]

We have our dockerized-gemstash on docker hub ...

• Image: https://hub.docker.com/r/zappi/gemstash/
• Source: https://github.com/Intellection/docker-gemstash

It uses automated builds to generate zappi/gemstash:<version> and zappi/gemstash:latest then cut a release i.e. git tag and git push --tags.

It applies Docker's best practices and has pretty much everything mentioned in https://github.com/bundler/gemstash/issues/61#issuecomment-220228611 and includes samples of how to run in SQLite, MySQL and PostgreSQL modes.

Usage examples are in the README ... it takes less than 5 minutes to get started and have something working.