Since it's not mentioned somehow, I'll recommend Dokku. It does exactly what this author wants, and I use it to deploy all my side projects.<p>Dokku has been around for years but still gets significant improvements. It doesn't support scaling to multiple boxes (at least not without some work of your own), but it's great for smaller deployments.<p><a href="https://dokku.com/" rel="nofollow">https://dokku.com/</a>
In the docker-compose.yml file it has:<p><pre><code> # expose port to localhost too
- "8000:8000"
</code></pre>
I never used ufw-docker but normal behavior with Docker here would publish 8000 to the outside world allowing someone to bypass your proxy and directly visit <a href="http://example.com:8000" rel="nofollow">http://example.com:8000</a>. Does ufw-docker not do that? The comment hints that they probably want to use "127.0.0.1:8000:8000" instead of "8000:8000" to be explicit, or at the very least should call out that ufw-docker is doing something special to block it because by default using 8000:8000 is quite dangerous to use with Docker and iptables.<p>I'm also curious about this quote:<p>> Docker does not play well with iptables, so I use ufw-docker to set up the firewall.<p>I never had any issues using iptables with Docker. What doesn't play nicely?
I am curious about the strategy to build the prod container on the prod infrastucture.<p>What level of concern is there about the reproducibility and reliability of such builds? I've had docker containers stop building due to unknown dependencies disappearing or ageing out.<p>And then presumably depending what kind of in code base it is, you could have some very intensive tasks and / or large containers involved in doing that build - which may itself cause some degradation of service or require a bigger server than you would need just to run the app.<p>I'd be interested in seeing a version of this that pulled the image from a CI/CD container registry - or does that defeat most of the purpose?
For a simpler option without Docker, but still with GIT Heroku-style, check out Polybox[0].<p>Polybox[0] is an itty-bitty PaaS that uses git push to deploy micro-services and websites on your own servers.<p>[0]<a href="https://github.com/mardix/polybox" rel="nofollow">https://github.com/mardix/polybox</a>
The current state of deployments (and dev environments in general) are a hot mess, especially for people who are not active developers, and just ocassional programmers. I update a few different web apps every year (or two), and each time, it is a nightmare. Unless, of course, I'm doing a simple drag and drop into Filezilla. In that case, it's effortless. The difference? The ridiculous tools I need to use just to get the code compiled and ready to deploy, much less somehow figure out how to actually connect to the server. This can make the absolute most simple changes not worth it, because I don't want to lose a day to debugging the inevitable problems that happen when I try to get the dev environment started. And yes, sadly, they are inevitable. Especially after letting things sit for a year.
we're working on TinyStacks to solve this - we've built the fastest way to deploy and maintain your Docker app on AWS.<p>In one click, TinyStacks takes your app code on GitHub and spins up all the necessary infrastructure with a fully automated pipeline - all on your AWS. Just git push.<p>We just started onboarding a few customers on Fri and would love to onboard a few more. Email me: safeer@tinystacks.com
I often wonder if this is going to how the future of CI/CD will be like. Instead of platform specific yaml files, you could leverage Multi-stage dockerfile. What would be cool is certain stage could run in parallel, may be you could skip certain stages. You could use the "gitops" style to deploy. And viola, you have a build system, that builds locally and remotely independent of the CI/CD platform.
This gives me a couple of ideas for piku (<a href="https://github.com/piku" rel="nofollow">https://github.com/piku</a>)...
I made a tool that does exactly this [0] wrapped up in a tiny little server! Main reason I did that was because I found myself creating "compose apps", where it was some self-hosted thing that I spent a lot of time managing without version control or in a deterministic manner.<p>For ingress, nginx-proxy (or traefik or caddy) listens for when a container starts on the network (auto attached by pcompose) but you still have all of the flexibility of docker-compose. Build happens on push if you have that defined in compose, so on and so forth.<p>Was able to even create some simple "convenience" ssh methods where you can trigger docker-compose commands or tail logs/exec into container directly over ssh. Definitely super crude and not really for production, but works great for apps that I just want to run and forget about.<p>[0] <a href="https://github.com/antoniomika/pcompose" rel="nofollow">https://github.com/antoniomika/pcompose</a>
I found caprover to be great for simple web apps. the git push and build on prod server feels like a remnant from before proper ci/cd with docker built separately was as available.
This is already not the best solution, there if you want “heroku style” then:
1. Install podman
2. Setup some container registry
3. Setup GitHub actions to build and push container
4. Setup podman for auto update
5. Push code and wait...<p>Much easier than hacking with bash and git.
Pushing source code to a remote server is bad!