4 ms·

This is really cool. If you're using Ubuntu or Debian as your base OS then you really should be managing your software with something like this and offloading y

by _qc3o 12y ago

This is really cool. If you're using Ubuntu or Debian as your base OS then you really should be managing your software with something like this and offloading your deployment to it as well. The benefits of a setup like that are dead-simple rollbacks and deployment scripts.

chrisan 12y ago
I like the concept, but wouldnt it be better to offload deployment/rollbacks to docker?
- hosay123 12y ago
  Aptly is a repository manager, it works in terms of tightly defined package versions and dependencies. Docker is for deployment, it works in terms of graphs of filesystem images. The tools do slightly overlap in use case, but they operate in entirely different domains. It wouldn't be unreasonable to mix both in the same project, but there is no hard rule for when this would be appropriate.
  - qwerta 12y ago
    I think I will stick with a Docker. DEB packages are very complicated and this tool does not really handle dependency conflits and so on that well. Plus it does not work with RPM and other packages systems.
    - icebraining 12y ago
      DEB packages are very complicated Not really, it's just a tar file with some metadata. Using fpm¹, making packages from a directory is extremely simple. I've been building internal packages from our different components, and the build script only has three or four lines. And besides, even Dockerfiles often use apt/yum. ¹ https://github.com/jordansissel/fpm https://github.com/jordansissel/fpm
      - smira 12y ago
        I use fpm to build aptly .deb packages, it is extremely simple to use compared to usual source package + build path. This is a problem for Go programs, due to multiple unversioned (usually) dependencies on other Go libraries.
    - robinson-wall 12y ago
      I'm currently working on transitioning to a Docker-based infrastructure. My existing system builds .debs and pushes them to an internal repository (reprepro rather than aptly because aptly was in its infancy when I built it). I'm not going to be building .debs for installation inside Docker containers (turtles all the way down) but I would still consider something like aptly for storing and managing any obscure dependencies that my applications might require, and for maintaining a mirror on the local network to speed up image builds.
    - ShawnMilo 12y ago
      A container. Not "a Docker." Docker is a tool for using containers via the LXC project.
      - vacri 12y ago
        A "docker image". Docker images are more than just containers, though they are run in containers.

by _qc3o 12y ago

chrisan 12y ago

I like the concept, but wouldnt it be better to offload deployment/rollbacks to docker?

hosay123 12y ago
Aptly is a repository manager, it works in terms of tightly defined package versions and dependencies. Docker is for deployment, it works in terms of graphs of filesystem images. The tools do slightly overlap in use case, but they operate in entirely different domains. It wouldn't be unreasonable to mix both in the same project, but there is no hard rule for when this would be appropriate.
- qwerta 12y ago
  I think I will stick with a Docker. DEB packages are very complicated and this tool does not really handle dependency conflits and so on that well. Plus it does not work with RPM and other packages systems.
  - icebraining 12y ago
    DEB packages are very complicated Not really, it's just a tar file with some metadata. Using fpm¹, making packages from a directory is extremely simple. I've been building internal packages from our different components, and the build script only has three or four lines. And besides, even Dockerfiles often use apt/yum. ¹ https://github.com/jordansissel/fpm https://github.com/jordansissel/fpm
    - smira 12y ago
      I use fpm to build aptly .deb packages, it is extremely simple to use compared to usual source package + build path. This is a problem for Go programs, due to multiple unversioned (usually) dependencies on other Go libraries.
  - robinson-wall 12y ago
    I'm currently working on transitioning to a Docker-based infrastructure. My existing system builds .debs and pushes them to an internal repository (reprepro rather than aptly because aptly was in its infancy when I built it). I'm not going to be building .debs for installation inside Docker containers (turtles all the way down) but I would still consider something like aptly for storing and managing any obscure dependencies that my applications might require, and for maintaining a mirror on the local network to speed up image builds.
  - ShawnMilo 12y ago
    A container. Not "a Docker." Docker is a tool for using containers via the LXC project.
    - vacri 12y ago
      A "docker image". Docker images are more than just containers, though they are run in containers.