[HN Gopher] Heroku-style deployments with Docker and Git tags
       ___________________________________________________________________
        
       Heroku-style deployments with Docker and Git tags
        
       Author : polyrand
       Score  : 68 points
       Date   : 2021-04-25 19:24 UTC (3 hours ago)
        
 (HTM) web link (ricardoanderegg.com)
 (TXT) w3m dump (ricardoanderegg.com)
        
       | oweiler wrote:
       | Not a huge fan of Kubernetes myself but Deployments solve that
       | problem out of the box with much less code.
        
         | nickjj wrote:
         | Right and it does it in a way where everything doesn't fall
         | apart if your stack is more involved than a web server.
         | 
         | For example, in the author's script wanting to run a background
         | worker ramps up the complexity by a lot but with Kubernetes
         | this would be adding 1 more deployment and you're done.
         | 
         | For most of my own stuff I just run 1 copy on 1 server and
         | configure nginx to queue up requests that fail due to a 502 and
         | then release them in the order they were received when the
         | back-end is available again. This way you don't have hard down
         | time. While your app restarts during a deploy the user only
         | gets a busy mouse cursor for a few seconds while your app boots
         | up. No load balancer needed. Lua scripts and nginx are a
         | powerful combo.
        
         | polyrand wrote:
         | I also use Kubernetes at work and somewhat agree with your
         | point, but there are a few downsides.
         | 
         | The method I explain in this post takes 5 minutes to set up in
         | any VPS, 1 minute if you have a template to copy-paste. You can
         | maybe do the same using k3s, but I still think there's more
         | complexity involved.
         | 
         | This method also builds the Docker containers in the same VPS,
         | so you don't need a container registry or a build server.
         | 
         | I came up with this way of doing things because I was already
         | doing all that by hand. Then I learned about git hooks and
         | custom remotes and I thought it was a handy way to automate it
         | without crossing the k8s line.
         | 
         | I personally find it a lot simpler. If you remove the comments
         | and wrap a couple of things in bash functions it's quite
         | straightforward.
        
           | merb wrote:
           | > k3s, but I still think there's more complexity involved.
           | 
           | which complexitiy do you had with k8s?
           | 
           | > If you remove the comments and wrap a couple of things in
           | bash functions it's quite straightforward.
           | 
           | ah yeah...
        
         | nfrankel wrote:
         | That's because you don't deal with state
        
           | gravypod wrote:
           | If you need persistent state is there much of a difference
           | with this approach and a StatefulSet with replicas=1?
        
       | zmmmmm wrote:
       | I am curious about the strategy to build the prod container on
       | the prod infrastucture.
       | 
       | 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.
       | 
       | 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.
       | 
       | 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?
        
       | lucassen wrote:
       | 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.
        
       | rcarmo wrote:
       | This gives me a couple of ideas for piku
       | (https://github.com/piku)...
        
         | polyrand wrote:
         | I love piku! I've never had the chance to use it, but I've read
         | a significant part of the code, and its philosophy has
         | influenced my approach to devops!
        
         | StavrosK wrote:
         | This is very interesting! Is it a Dokku alternative?
         | 
         | I wrote a similar thing yesterday:
         | 
         | https://gitlab.com/stavros/harbormaster
         | 
         | Mine is basically Balena, though, so it lets you deploy a bunch
         | of Compose repos and doesn't handle ingress. Maybe I could
         | switch to Piku instead.
         | 
         | EDIT: Ah yeah, it looks like Piku is geared towards web servers
         | and handles ingress, mine is more geared towards consumer stuff
         | and doesn't handle ingress itself.
        
       | safeerm wrote:
       | we're working on TinyStacks to solve this - we've built the
       | fastest way to deploy and maintain your Docker app on AWS.
       | 
       | 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.
       | 
       | We just started onboarding a few customers on Fri and would love
       | to onboard a few more. Email me: safeer@tinystacks.com
        
         | mgr86 wrote:
         | Git push, so it's a post-receive hook? I do the same with my
         | deployments. I also like to set up make files because most
         | newcomers to the project can grok a makefile. Without having to
         | learn a new build tool.
        
       | nickjj wrote:
       | In the docker-compose.yml file it has:                     #
       | expose port to localhost too           - "8000:8000"
       | 
       | 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 http://example.com:8000.
       | 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.
       | 
       | I'm also curious about this quote:
       | 
       | > Docker does not play well with iptables, so I use ufw-docker to
       | set up the firewall.
       | 
       | I never had any issues using iptables with Docker. What doesn't
       | play nicely?
        
       ___________________________________________________________________
       (page generated 2021-04-25 23:00 UTC)