The use of ls in this way is not good form: cd /root for project in $(ls go-cicd); I think a better expression would be: for project in ./* do [ -d "$project" ] || continue ...
Why is that not good form?
My deployment platform is a shell script
61–70 of 141 posts
Re: My deployment platform is a shell script
#62Shell scripts are a more evolved form of programming and nobody can change my mind on that. They require less work, they're easier to make, they're flexible, compatible, composable, portable, small, interpreted, and simple. You can do more with few characters and do complex things without the complexity of types, data structures, locks, scoping, etc. You don't write complex programs in it, but you use complex program…
I agree with most of this, my biggest issue is how hard it is for me to recall any moderately complex shell syntax (or the slightly different Makefile syntax). LLMs largely solve that for me.
I would RTFM so I actually learn something instead of using """AI""" regurgitation.
Re: My deployment platform is a shell script
#63> my script will never:
> - 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.
Re: My deployment platform is a shell script
#64I also started with a simple shell script. Upload sources, build on the target system (golang) and restart the systemd service(es).
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.
Re: My deployment platform is a shell script
#65Re: My deployment platform is a shell script
#66I use similar things for bigger (multi-server) deploys too. It's light and it just works and works for decades without changes/updates. People say it's brittle; I have a proof of n>0 that this is not the case compared to many other solutions, this post making that point too. Sh/bash/perl(8) have been around forever, they don't break after update etc. I sadly don't recommend it for my day job, simply because of liabil…
[flagged]
Just yesterday I was working on a monitoring agent that was a python script deployed through gitlab-ci, and executed inside a docker container through logstash.
I bet you could do the same with about 5 lines of shell (wget|grep|curl -XPOST). It would be simpler, easier to modify, and it wouldn't ever break.
Shell scripts aren't necessarily messy or complex.
Re: My deployment platform is a shell script
#67Earlier quoted context omitted.
The bash man page is my bible. It's dense and long but it always has the answers, you just gotta know where to look.
When people mention `bash` it's immediately a code smell. In order to write portable shell scripts, it must be only POSIX `sh`. If the need ever arises for a more complex data structure, typically I jump into AWK since it's also POSIX compliant. Here's a note from the Ubuntu recommendation: https://wiki.ubuntu.com/DashAsBinSh
I've never been in a situation where I had to care. Bash is everywhere, it's a de facto standard of its own. Even a lot of buildroot and Alpine based Linux deployments, which don't come with bash by default, usually have bash added to them.
Re: My deployment platform is a shell script
#68As a pythonista, I am a huge fan of the plumbum library as a replacement for bash. It makes it very straightforward to run a sequence of *nix commands, but you get all the simplicity and power of the python language in terms of loops and functions and so forth. These days, I do all my server management and deployment scripts with python/plumbum.
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.
Re: My deployment platform is a shell script
#69Not to deride this (too much), but the 'robustness' of deployments with shell scripts is tempting bait. Things are until they aren't, 'nobody rides for free' - decide what you're willing to pay. 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 scri…
Putting SAVEIFS=$IFS IFS=$(echo -en "\n\b") or something similar at the top of the script might not come across as comparable to adopting Ansible to some people.
Pro tip: unsetting IFS has the same effect as saving and restoring the old value.
Re: My deployment platform is a shell script
#70The use of ls in this way is not good form: cd /root for project in $(ls go-cicd); I think a better expression would be: for project in ./* do [ -d "$project" ] || continue ...
Why is that not good form?
Not that I agree 100%, but the topic is covered fairly well here: