HN Explorer

Show HN: DCPM – Docker Compose Package Manager

59 points by hasmolo ↗ HN
Hey y'all,

I've been using docker compose a lot in my local network, and managing setup between machines is a bit of a pain in the ass for me. I wanted an easy way to share complex configurations. At the moment most docker compose package management is done by adding a docker-compose.yml to your repo, adding a bunch of setup instructions, and hoping they are well followed. This didn't feel like a smart way to go about it to me.

I wanted to create a way to create a complex package, say a series of related or linked services, and provide some meaningful way to have users install it. That's why I built DCPM. It provides a few things for you:

  1. A nice CLI to interact with
  2. A place to store these files and configuration
  3. A way to setup new projects that's not just reading a readme
To achieve these goals I built the @dcpm/cli and blobs.dcpm.dev. The cli allows you to upload and download blobs, and the back end allows you to have a persistent storage to use. I've also built a really simple front end for searching packages.

This is a very early alpha. There is a lot left to improve, but I feel enough of the core concepts are here to get some early feedback and improve the tool. Any and all feedback are super welcome. Here are some links for you:

Docs: https://docs.dcpm.dev

Search: https://app.dcpm.dev

CLI: https://www.npmjs.com/package/@dcpm/cli

GitHub: https://github.com/hweeks/dcpm

fyi: there's a nonzero chance that the DB will be wiped once we exit alpha and enter beta

- hamsolo/hweeks

13 comments

[ 3.3 ms ] story [ 8.4 ms ] thread
drizze
FYI you have a ref to 0.0.0.0:8000 as your homepage from the docs.dcpm.dev link

<a href="http://0.0.0.0:8000/" title="Docker Compose Package Manager" aria-label="Docker Compose Package Manager" class="md-header-nav__button md-logo">

edit: looks like a cool project though! congrats on shipping!

nodesocket
Is there a cleaner way to drop a user into a shell of a docker container with ports exposed instead of doing:

  services:
    web:
      entrypoint: /bin/bash
And then:

  docker-compose run --service-ports web
yjftsjthsd-h
docker-compose exec?
nodesocket
So would just be:

docker-compose exec web /bin/bash

Saves having to add --service-ports

castis
exec only works on specific running containers so you'll need the container id for this

    exec -ti f635776c2d08 /bin/bash
i do this often enough that i keep this in a makefile so i can do it by image name

    docker exec -ti `docker ps | grep 'container-name' | awk '{print $$1}'` /bin/bash
yjftsjthsd-h
You only need to specify the container by ID if you're using docker directly; if you use docker-compose then you can use the service name and you don't need the `-ti`
hasmolo
Generally I use

    docker-compose exec <service> sh
[deleted]
(comment deleted)
e12e
I'm not sure what you're asking here - docker/docker-compose have both run and exec - they both start a process in a container. Run creates a new container, exec starts a process in a running container.

Both adhere to entrypoint and cmd; without arguments, entrypoint is called with cmd as argument (eg docker run ngnix would call the entry-script, which would call cmd - together they typically end up running nginx). If an argument is given, cmd is replaced. You would typically want that command to be bash: docker run ngnix bash / docker-compose run ngnix bash.

One difference is that docker-compose uses -ti (--tty/--interactive) by default, plain docker does not.

TL;DR to debug a service while it runs, start it like so:

docker-compose start web

And login to a shell in the container:

docker-compose exec web bash

(with ps you should now see your web server running next to your shell)

To run a shell inside a service, without starting the application itself:

docker-compose run --rm web bash

(your shell is now in a fresh container, your application typically won't be running (if there's no crazy entrypoint/init stuff going on) - and the container will be removed once you exit the shell.

gitgud
Docker-compose has always been a great little tool to spin up a collection of integrated services (like a LAMP stack). It has just the right level of complexity for many projects.

Packaging these collections up as reusable apps is smart, but isn't this what kubernetes helm charts are?

From first glance the "Search" domain is very unintuitive. I typed in "web" and "app" with no results. Your better off showing a list of most downloaded or something similar to npm's search.

> "fyi: there's a nonzero chance that the DB will be wiped once we exit alpha and enter beta"

This is honest, but it's not a good look to lose data. If it's possible, simply backup the data between updates... I wouldn't trust something that wipes my data.

Anyway great little project, hope it continues and grows.