Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

My deployment platform is a shell script

j3s.sh

Post reply on HN
Print view View original

81–90 of 141 posts

Re: My deployment platform is a shell script

#81

Post by chasil »

adamtaylor_13 wrote: post #55
chasil wrote: post #33

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?

There are several reasons.

- Running ls forks an unnecessary process.

- The ls may be aliased with "-F" (or -p) which will corrupt the filenames.

- Environment variables may otherwise (unexpectedly) manipulate ls behavior.

- Files with spaces will not be evaluated correctly.

- Hostile files can be placed that mimic command line arguments.

The shell should evaluate filenames itself; it is very capable of doing so.

POSIX ls: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/l...

Re: My deployment platform is a shell script

#82

Post by snippy »

z_zetetic_z wrote: post #59

Or, you could use NixOS and just declare your systems in some text files, git commit; git push. You build script becomes: while true; do git pull nixos-rebuild switch sleep x done That's it. You can even do it remotely and push the new desired state to remote machines (and still build on the target machine, no cross compile required). I've completely removed Ansible as a result and no more python version mismatches,…

Sounds interesting. Let's say the software is a web backend. Can you deploy it like this with zero downtime? So that the new version starts, new traffic goes to it, and the old version handles its active requests to completion and then shuts off.

Re: My deployment platform is a shell script

#83

Post by morkalork »

kragen wrote: post #75

here's the deployment script i use most often 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.' dev3.git is the origin for dev3, so the `git pull` in there pulls fro…

I still get a chuckle remembering a co-worker called this the "pull and pray" method.

Re: My deployment platform is a shell script

#84

Post by kragen »

morkalork wrote: post #83
kragen wrote: post #75

here's the deployment script i use most often 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.' dev3.git is the origin for dev3, so the `git pull` in there pulls fro…

I still get a chuckle remembering a co-worker called this the "pull and pray" method.

yeah, dev3 doesn't really require high reliability, so i only have to pray to the small gods

Re: My deployment platform is a shell script

#85

Post by anonyfox »

I have a similar deploy.sh script for my go projects, with a slight twist:

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.

Re: My deployment platform is a shell script

#86

Post by cess11 »

riddley wrote: post #69
cess11 wrote: post #15

Earlier quoted context omitted.

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.

Ah, nice, thanks.

I've been cargo-culting this for ages without thinking much about it.

Re: My deployment platform is a shell script

#87

Post by bravetraveler »

hawski wrote: post #20
rkta wrote: post #17

Earlier quoted context omitted.

Parsing ls is an anti-pattern, but the author says it works for years - we all do mistakes and as long as it works you don't notice. And it's an easy fix: - for project in $(ls go-cicd); do + cd go-cicd || exit 1; for project in \*; do

I would suggest not to mess with the current working directory and instead do something like this: for project in go-cicd/*; do project="${project#*/}"

Indeed, thank you for mentioning that - I was going to suggest similar.

That said, if you do (ie: scratch files, things outside of control, whatever), consider the directory stack:

https://www.gnu.org/software/bash/manual/html_node/Directory...

Using 'pushd' and 'popd' can save your fingers/brain from getting lost in context.

Re: My deployment platform is a shell script

#88

Post by cess11 »

bravetraveler wrote: post #22
cess11 wrote: post #15

Earlier quoted context omitted.

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.

I knew giving specific examples would lead this way, that's not my point. This case has been handled. Others? There isn't anything really insightful here. Someone pleased with a script has not yet grown beyond the needs of it. Yay. The more portable/maintainable version of this is a playbook or whatever. Someone wrote and tested a better version of whatever Work Unit as a module. Wheel enthusiast is pleased with thei…

OK, and I wouldn't have used either Ansible or bash. I would have used picolisp, which is clearly superior for this task due to the flexibility that comes with the deep POSIX integration.

When I think about excellent software Ansible isn't the first that comes to mind either. Clearly it's different for you, and the person who wrote the TFA doesn't agree with me either.

Re: My deployment platform is a shell script

#89

Post by chasil »

kragen wrote: post #77
mattbuilds wrote: post #54

Earlier quoted context omitted.

It’s funny because in my many years of development I don’t think I’ve ever encounter a “mess of shell scripts” that was difficult to maintain. They were clear, did their job and if they needed to be replaced it was usually simple and straightforward. Can’t say the same for whenever the new abstraction of the day comes along. In my experience what the OP is saying is exactly my experience. The abstractions get picked…

i have encountered messes of shell scripts that were difficult to maintain; in my first sysadmin job in 01996 i inherited a version control system written as a bunch of csh scripts, built on top of rcs but they were messy not because they lacked 'abstractions' but because they had far too many i think shell scripts are significantly more bug-prone per line than programs in most other programming languages, but if the…

If it was in RCS, then you could directly move the archives under a CVSROOT and use them natively.

CVS had been out since Brian Berliner's version of 1989.

I actually moved a PVCS archive into RCS->CVS this way, and I'm still using it.

Re: My deployment platform is a shell script

#90

Post by chasil »

z_zetetic_z wrote: post #59

Or, you could use NixOS and just declare your systems in some text files, git commit; git push. You build script becomes: while true; do git pull nixos-rebuild switch sleep x done That's it. You can even do it remotely and push the new desired state to remote machines (and still build on the target machine, no cross compile required). I've completely removed Ansible as a result and no more python version mismatches,…

Instead of saying:

  while true
You can instead say:

  while :
There is actually a /bin/true, which could involve the fork of a new process for each iteration of the loop. The form that I have shown you is guaranteed not to fork.
Post reply on HN