by j3s on 4/9/24, 10:58 PM with 138 comments
by anonzzzies on 4/10/24, 11:20 AM
I sadly don't recommend it for my day job, simply because of liability. When something messes up with ansible, terraform, docker, cloudformation etc, no-one gets any blame because 'complex systems', 'it happens' etc etc; with a simple script going wrong, they would hang me high even though it probably saves a crap load in maintenance, compute etc over the 10s of years. Same reason we use clusters and IaC while of course nothing we do needs it; if an aws cluster goes down, no-one but aws gets blamed, while if the $2 postgres vps@cheapafhosting (with an higher uptime than that aws cluster by the way; human error downed it a few times, short, but still) is down even for a ping, everyone is upset and pointing fingers.
by throwaway458864 on 4/10/24, 12:33 PM
That said, it's a tool. Like any tool, it depends how you use it. People who aren't trained on the tool, or don't read the instruction manual, might get injured. I'd like to see a version of it that is safer and retains its utility without getting more complicated, but it would end up less useful in many cases. Maybe that's fine; maybe it needs to be split into multiple tools.
by chasil on 4/10/24, 11:36 AM
cd /root
for project in $(ls go-cicd);
for project in ./*
do [ -d "$project" ] || continue
...by pevey on 4/10/24, 11:30 AM
by Ingon on 4/10/24, 1:23 PM
Then, I needed to make another machine like this, so enter Ansible. This worked well for a long time, and was relatively content with it. Along the way, I leaned about nix (and enough of it) to adopt a simple flake to pull out my tools (like golang, ansible, terraform) through. For a long time, I used it like this (e.g. still ansible, but I started building locally)
Finally, I learned enough nix to adopt NixOS. Now, I've converted my project to a nix package and a NixOS module, which allows me to totally describe the state of the machine I want. With this, remote builds and colmena (mostly for pushing secrets), I deploy a complete system, including my own software.
by 1vuio0pswjnm7 on 4/10/24, 4:53 AM
Shell scripts written in NetBSD sh/Debian ash will work for as long as I live.
by z_zetetic_z on 4/10/24, 1:15 PM
You build script becomes:
while true; do
git pull
nixos-rebuild switch
sleep x
done
I've completely removed Ansible as a result and no more python version mismatches, no more hunting endless task yaml syntax, no more "my god ansible is slow" deplyments.
by bravetraveler on 4/10/24, 9:20 AM
Example: this interprets the output of 'ls'. Reliability is dependent on good quoting/never introducing a project with spaces
Ansible is a nice middle ground, personally. I write the state that differs, use a library of scripting.
by Gys on 4/10/24, 12:09 PM
by pfitzsimmons on 4/10/24, 1:28 PM
And while simple is great, the necessary features not included in OP's scripts is that I want to spin up the new instance in parallel, verify it is running correctly, and then switch nginx or the load balancer to point to the new server. You are less prone to break production and you get zero downtime deploys.
by codegeek on 4/10/24, 12:54 PM
by mediumsmart on 4/10/24, 7:52 AM
pushthis="rsync -avzh --del ~/path.local/ somedude@path.online:path.online"
by gregsadetsky on 4/10/24, 2:56 PM
How do you manage domain names, who deals with the ssl certificates, how do you set environment variables i.e. "secrets", how can you run postgres, how do you run remote commands i.e. dbmigrate.py, etc.
A friend and I have been working for a few months on a project to simplify this - we're not the first to do an open source IaC, but we're scratching our own itch on a lot of features that we've been missing. It's basically "deploy with git push to your own VPS and manage everything with a CLI".
I'd love to ask - what do people feel is mostly lacking from OP's script? Which features seem like the most important when deploying/managing a remote server? How do you choose if you're going to use Ansible or K8S or a script, or a full blown IaC i.e. Heroku? Is it price/ownership (i.e. having full control over the machine)/ease of use/speed of deployment/something else? Thanks!
by gigatexal on 4/10/24, 11:22 AM
by kragen on 4/10/24, 1:49 PM
http://canonical.org/~kragen/sw/dev3.git/hooks/post-update
#!/bin/sh
set -e
echo -n 'updating... '
git update-server-info
echo 'done. going to dev3'
cd /home/kragen/public_html/sw/dev3
echo -n 'pulling... '
env -u GIT_DIR git pull
echo -n 'updating... '
env -u GIT_DIR git update-server-info
echo 'done.'
it doesn't have the 60-second lag and it doesn't load the server all the time. it also doesn't run `go build` or restart a server with openrc, but those would be easy things to add if i wanted them
by mnahkies on 4/10/24, 6:25 AM
I wouldn't use it for serious stuff, but it's been working great for my random personal projects (biggest gap is if something crashes it'll stay crashed until manual intervention currently)
by tacone on 4/10/24, 1:46 PM
It will connect over ssh, pull the code, build the containers and restart them (scripts/live is just a wrapper around docker-compose).
If the build fails, the services will keep running.
The only problem I have is that hitting CTRL+C in the very moment the containers are being restarted will leave me with the services down.
by zoidb on 4/10/24, 11:25 AM
A shell script that deploys a couple config files and off you go. Use different accounts for each service for isolation and put all of your static files in your binary using embed.FS. No need for fancy configuration management or K8s.
by anonyfox on 4/10/24, 2:05 PM
I compile my Go projects to a binary on a github action, scp it to the server, ssh into it and restart - all done in my deploy.sh and the GHA itself only installs Go and deps (its cached) and then calls that deploy.sh script which sits right in the repo itself.
Super happy with it. Speaking as a previous DevOps guy that got sick of AWS complexities.
by rcarmo on 4/10/24, 10:21 AM
by OddMerlin on 4/10/24, 11:54 AM
Don’t get me wrong, I love bash scripts like any other old hat, but Ansible scratches this exact itch.
You’ve got playbooks that can execute shell, provide logging, better management, history of execution, fleet management, and it’s light weight. And there’s a robust community of shared modules, etc.
by lyxell on 4/10/24, 10:26 AM
Polls a docker registry and automatically restarts the container with the same flags that it was started with using the latest image.
by fforflo on 4/10/24, 2:54 PM
It's 2024 and you're not developing the next vim or Postgres. Use bash.
by medv on 4/10/24, 11:35 AM
by strzibny on 4/10/24, 12:41 PM
by dvfjsdhgfv on 4/10/24, 11:18 AM
by philkrylov on 4/10/24, 10:53 AM
by chapterjason on 4/10/24, 6:04 AM
by yodaforever on 4/10/24, 8:33 AM
by TheCapeGreek on 4/10/24, 12:23 PM
Especially as more and more new, easy/low config tools come out like Caddy, this gets simpler over time.
I have a testbed boilerplate project for Laravel in which server provisioning & deployments are done by bash scripts over SSH. Excluding comments/spacing, the provisioning script is 35 lines of mostly installing dependencies and minor file template copies. For simpler projects not needing queue workers and/or not using more "exotic" tech like Laravel Octane, this could probably be cut down to 30.
TL;DR do the simplest thing that works for you and move on with life - the value in your project, if you intend to deploy it, is for it to be used.
by makz on 4/10/24, 3:57 PM
by danpalmer on 4/10/24, 1:22 PM
> - go down
I've had cron log files get too big and causes issues.
> - require an upgrade
I can't count the number of times unattended-upgrades has broken something.
> - force me to migrate
Let's hope the OS is still receiving security updates, because installing on a VPS like this always has a high migration cost.
This sort of deployment is a fair starting point, but let's not pretend it's some perfect ideal.
....
Look. For deploying a blog, sure, but no one is deploying their blog on k8s. There is a reason why big complex deployment and orchestration systems exist, because there are use-cases for them. This is not one of them, but there's no need to stick your head in the sand over requirements and pretend they don't exist.
by dartos on 4/10/24, 3:12 AM
by logro on 4/10/24, 10:25 AM
my script will never:
- go down
- require an upgrade
- force me to migrate
- surprise me
- keep me up at night
by RandomWorker on 4/10/24, 12:55 PM