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.
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.
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.
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.
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.
