5 ms·

Show HN: DCPM – Docker Compose Package Manager

59 points by hasmolo 7y ago

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 https://docs.dcpm.dev Search: https://app.dcpm.dev https://app.dcpm.dev CLI: https://www.npmjs.com/package/@dcpm/cli https://www.npmjs.com/package/@dcpm/cli GitHub: https://github.com/hweeks/dcpm 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

drizze 7y ago
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/" 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!
- hasmolo 7y ago
  thanks, I'll push a fix
nodesocket 7y ago
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 7y ago
  docker-compose exec?
  - nodesocket 7y ago
    So would just be: docker-compose exec web /bin/bash Saves having to add --service-ports
    - castis 7y ago
      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 7y ago
        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 7y ago
  Generally I use docker-compose exec <service> sh
- deleted 7y ago
  [deleted]
- e12e 7y ago
  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.
barell 7y ago
Would be nice to see some example. When I open search there are no results.
- hasmolo 7y ago
  Here's my base package https://app.dcpm.dev/package/home-media https://app.dcpm.dev/package/home-media
gitgud 7y ago
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.

59 points by hasmolo 7y ago

drizze 7y ago

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/" 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!

hasmolo 7y ago
thanks, I'll push a fix

nodesocket 7y ago

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 7y ago
docker-compose exec?
- nodesocket 7y ago
  So would just be: docker-compose exec web /bin/bash Saves having to add --service-ports
  - castis 7y ago
    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 7y ago
      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 7y ago
Generally I use docker-compose exec <service> sh
deleted 7y ago
[deleted]
e12e 7y ago
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.

barell 7y ago

Would be nice to see some example. When I open search there are no results.

hasmolo 7y ago
Here's my base package https://app.dcpm.dev/package/home-media https://app.dcpm.dev/package/home-media

gitgud 7y ago

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.