5 ms·

For those who have even simpler needs (like side projects, or 1 dev projects), I found using simply docker and git to be plenty enough. Basically, you can crea

For those who have even simpler needs (like side projects, or 1 dev projects), I found using simply docker and git to be plenty enough. Basically, you can create a bare git repository on your server (`git init --bare`), and put a `hooks/post-receive` script within it that will clone sources in a temporary directory, build the docker image and rotate containers. That way, you can `git push` to build and deploy, and it's easy to migrate server. The added bonus is that you now have a central git repos that can act as backup, so you don't need github or gitlab. The main painpoint, which I find dokku interesting for (and I assume caprover too) is zero-downtime deployment. But well, if this is critical, you probably need something more extensive.

xu6ahb8E 6y ago
Here is an example of post-receive script I use for that: #!/usr/bin/env bash export APP=appname export DOCKER_OPTS="" unset GIT_DIR rm -rf /home/username/apps/$APP cd /home/username/apps && \ git clone /home/username/git/$APP && \ cd $APP && \ echo building image && \ docker build -t $APP . if [[ "$?" != "0" ]]; then echo "error while building image." exit 1 fi echo "Stopping previous container..." docker stop $APP echo "Starting new container..." sleep 1 docker run -d --name $APP --rm $APP
- dugmartin 6y ago
  FYI, you can avoid the $APP directory removal and clone by doing: GIT_WORK_TREE=/home/username/apps/$APP git checkout master
  - xu6ahb8E 6y ago
    Yes, that's true, thanks for mentioning it. It comes from a time when I did not use docker so I wanted to get rid of build artifacts, but building within docker, this is not a problem anymore.
    - c17r 6y ago
      If you need to use your "old way" for something else, you can use 'git clean -fdx' which will remove all files and directories that git does not track.
- deleted 6y ago
  [deleted]
- phaemon 6y ago
  You should at least use `set -u` in this script, otherwise, at some point, you'll fail to set $APP and end up running: rm -rf /home/username/apps/ Guess how I learned this lesson? :)
  - Operyl 6y ago
    Ooooh, I need to start documenting my war stories. They'll make for a fun read at some point years down the line.
antoniomika 6y ago
I actually developed a system similar to this but used docker compose as an alternative to Procfiles and nginx+le to handle dynamic virtual hosting. It's actually a golang app that will automatically provision git repos with the necessary hooks and also allow you to exec into a container directly over SSH. I had the thought of using docker stack to achieve zero downtime but haven't had a chance to try that out. Happy to open source it if anyone is interested in using it.
- jensneuse 6y ago
  please do!
- njsubedi 6y ago
  Please open source it
- dzolvd 6y ago
  Would love to see it!
- 1337shadow 6y ago
  The problem with nginx based setups is that one wrong container option (label, env var, etc ...) may cause a syntax error in the nginx configuration file and then nginx won't start, so all services will be down. Loved apache, loved nginx, but I can see traefik is the only http server on my tech blog for the last years... Nginx is made to load a configuration: you don't have the auto-configuration that comes with service discovery. Service discovery is doable with a standard HTTP API through /var/run/docker.sock or /var/run/podman/podman.sock in more advanced systems. As such, service discovering HTTP servers are more reliable because it's built with a service isolation from the ground up: if one service has some poor value then it won't work, but it won't block the other services. Nginx is too far behind now, they might have some service discovery module, but even then the thing that happens when your configuration autogenerates (like with snapshot testing) is that you still have to read the configuration it generates. Traefik offers a great dashboard for this so it's even more pleasant than reading a configuration file that you didn't even write ;) For sure, I bet that in a patch into something like CapRover (or your own solution), changing nginx to traefik would end up removing quite a lot of code ;) I'm not really sure what you mean "acheiving ZDD", ZDD is complicated any time there's a data schema migration, not to mention that containers deployment traditionally is "delete a container: KILL a process" and "create another one like cattle". uWSGI for example, could gracefully renew every worker process on SIGHUP, but re-creating the uWGSI process in another container defeats that. Maybe you have some kind of blue green deployment, maybe even canary, in this case I wonder if basing a container platform on configuration files such as those for nginx would really make it to ZDD. Would love to read more about your setup
rcarmo 6y ago
That is what Piku (https://github.com/piku https://github.com/piku) is all about. You can easily deploy containers through it as well.
babaganoosh89 6y ago
Caprover doesn't do zero-downtime deployment currently fyi
mcdoh 6y ago
Similar to this? https://www.digitalocean.com/community/tutorials/how-to-use-git-hooks-to-automate-development-and-deployment-tasks https://www.digitalocean.com/community/tutorials/how-to-use-...
1337shadow 6y ago
How exactly is the zdd you're talking about ? zdd for 100% of use case seems like quiet a rabbit hole, particularly when any kind of data migration needs to happen. I suppose my question is: at what point can we claim doing zdd ?
kybernetikos 6y ago
Really what I want for my side projects is just to be able to push my projects to github, and if they have a manifest file, they should just automatically spin up on a subdomain with the same name as the repository. I don't see why it should be any more complex than that, and I'd be happy to pay a small sum every year to have that.

xu6ahb8E 6y ago

Here is an example of post-receive script I use for that: #!/usr/bin/env bash export APP=appname export DOCKER_OPTS="" unset GIT_DIR rm -rf /home/username/apps/$APP cd /home/username/apps && \ git clone /home/username/git/$APP && \ cd $APP && \ echo building image && \ docker build -t $APP . if [[ "$?" != "0" ]]; then echo "error while building image." exit 1 fi echo "Stopping previous container..." docker stop $APP echo "Starting new container..." sleep 1 docker run -d --name $APP --rm $APP

dugmartin 6y ago
FYI, you can avoid the $APP directory removal and clone by doing: GIT_WORK_TREE=/home/username/apps/$APP git checkout master
- xu6ahb8E 6y ago
  Yes, that's true, thanks for mentioning it. It comes from a time when I did not use docker so I wanted to get rid of build artifacts, but building within docker, this is not a problem anymore.
  - c17r 6y ago
    If you need to use your "old way" for something else, you can use 'git clean -fdx' which will remove all files and directories that git does not track.
deleted 6y ago
[deleted]
phaemon 6y ago
You should at least use `set -u` in this script, otherwise, at some point, you'll fail to set $APP and end up running: rm -rf /home/username/apps/ Guess how I learned this lesson? :)
- Operyl 6y ago
  Ooooh, I need to start documenting my war stories. They'll make for a fun read at some point years down the line.

antoniomika 6y ago

I actually developed a system similar to this but used docker compose as an alternative to Procfiles and nginx+le to handle dynamic virtual hosting. It's actually a golang app that will automatically provision git repos with the necessary hooks and also allow you to exec into a container directly over SSH. I had the thought of using docker stack to achieve zero downtime but haven't had a chance to try that out. Happy to open source it if anyone is interested in using it.

jensneuse 6y ago
please do!
njsubedi 6y ago
Please open source it
dzolvd 6y ago
Would love to see it!
1337shadow 6y ago
The problem with nginx based setups is that one wrong container option (label, env var, etc ...) may cause a syntax error in the nginx configuration file and then nginx won't start, so all services will be down. Loved apache, loved nginx, but I can see traefik is the only http server on my tech blog for the last years... Nginx is made to load a configuration: you don't have the auto-configuration that comes with service discovery. Service discovery is doable with a standard HTTP API through /var/run/docker.sock or /var/run/podman/podman.sock in more advanced systems. As such, service discovering HTTP servers are more reliable because it's built with a service isolation from the ground up: if one service has some poor value then it won't work, but it won't block the other services. Nginx is too far behind now, they might have some service discovery module, but even then the thing that happens when your configuration autogenerates (like with snapshot testing) is that you still have to read the configuration it generates. Traefik offers a great dashboard for this so it's even more pleasant than reading a configuration file that you didn't even write ;) For sure, I bet that in a patch into something like CapRover (or your own solution), changing nginx to traefik would end up removing quite a lot of code ;) I'm not really sure what you mean "acheiving ZDD", ZDD is complicated any time there's a data schema migration, not to mention that containers deployment traditionally is "delete a container: KILL a process" and "create another one like cattle". uWSGI for example, could gracefully renew every worker process on SIGHUP, but re-creating the uWGSI process in another container defeats that. Maybe you have some kind of blue green deployment, maybe even canary, in this case I wonder if basing a container platform on configuration files such as those for nginx would really make it to ZDD. Would love to read more about your setup

rcarmo 6y ago

That is what Piku (https://github.com/piku https://github.com/piku) is all about. You can easily deploy containers through it as well.

babaganoosh89 6y ago

Caprover doesn't do zero-downtime deployment currently fyi

mcdoh 6y ago

Similar to this? https://www.digitalocean.com/community/tutorials/how-to-use-git-hooks-to-automate-development-and-deployment-tasks https://www.digitalocean.com/community/tutorials/how-to-use-...

1337shadow 6y ago

How exactly is the zdd you're talking about ? zdd for 100% of use case seems like quiet a rabbit hole, particularly when any kind of data migration needs to happen. I suppose my question is: at what point can we claim doing zdd ?

kybernetikos 6y ago

Really what I want for my side projects is just to be able to push my projects to github, and if they have a manifest file, they should just automatically spin up on a subdomain with the same name as the repository. I don't see why it should be any more complex than that, and I'd be happy to pay a small sum every year to have that.