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

91–100 of 141 posts

Re: My deployment platform is a shell script

#91

Post by bravetraveler »

cess11 wrote: post #88
bravetraveler wrote: post #22

Earlier quoted context omitted.

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.

Let's take a step back from names for a second - I feel we're getting a little distracted by that.

My gripe isn't with the tech, or even the solution. It's perfectly fine. I know I'm being overly critical, but I think they opened themselves to some judgement by making a post!

I would do something very similar. Sure, the tool wouldn't have the exact same name, but the mechanism would be ~the same~ very similar.

If the goal is to minimize surprises, the amount of effort put into something, etc - is it not best to follow the beaten path?

They're to be commended for making a solution that works well for them, and echoing the KISS methodology, I just don't think a shell script is it. Anecdotes are funny, I guess.

It's worked well for them - but I'm here because similar things have gone terribly for me. Small decisions can have big influence

Re: My deployment platform is a shell script

#93

Post by gregsadetsky »

There's a lot of good in that script - it's just that it doesn't seem to cover functionalities that I'm used to after years of deploying side and "real" (business, etc.) projects to Heroku and Render.

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!

Re: My deployment platform is a shell script

#94

Post by yjftsjthsd-h »

cqqxo4zV46cp wrote: post #41
anonzzzies wrote: post #27

I 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]

Are you sure you're not the one grinding an axe? Shell scripts are a mess but YAML isn't? On the happy path they can both be fine, and on the unhappy path they both suck.

Re: My deployment platform is a shell script

#95

Post by throwaway458864 »

nocombination wrote: post #52
throwaway458864 wrote: post #46

Earlier 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

Not every shell script has to be that portable. And even then, "POSIX compatible" shells vary in their "POSIXness". Sometimes using arrays is the right thing to do, or having a reliable indicator of the source script location, so you code to Bash 3. Sometimes associative arrays or something else is better, and your platform is known, so you code to Bash 4 or 5. Maybe all your users are Zsh users so you use that. So you can start by writing POSIX compatible scripts, but there's no sense in tying your hands if you don't need to.

The Bash manual also covers POSIX semantics, I just remember which is which. You're right that the Dash manual is a good place to check what is mostly POSIX (Dash isn't actually strictly POSIX). I would probably use Shellcheck with the correct shebang to double check what's compatible.

Re: My deployment platform is a shell script

#96

Post by bravetraveler »

prmoustache wrote: post #48
OddMerlin wrote: post #34

Why not use Ansible for something like this? 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.

I think even ansible is overkill for such a simple thing. Ansible use case works better when you need to do stuff on multiple hosts. For years I've started using and abandoned ansible and puppet recipes for setting up my own computers and everytime the conclusion was that I would spend more time installing git, ansible and puppet in the first place and debugging my recipes than using them. Now all my setup lives in s…

Ansible is great even for simple single-host 'shell scripts'.

Lean into the module ecosystem. Want to ensure a config file is a certain way? Jinja/template it, or use lineinfile instead of echo/shell redirects.

That's a lot of mumbo-jumbo. The point is, there's a lot of stuff scripts want to do. Ansible provides these as modules. Using the modules spares you from writing code to do something in a robust/repeatable way.

The 'line in a file' example is a good case, IMO. A shell script with redirection either requires specific code to look first, or simply endlessly append. With Ansible you don't have to do all of that.

Your script needs to do something when something changed? Ansible has you covered: handlers!

Python is right within reach too. I find it a way to write Python via YML, basically.

Re: My deployment platform is a shell script

#97

Post by icedchai »

cqqxo4zV46cp wrote: post #41
anonzzzies wrote: post #27

I 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]

Most CI/CD configurations are also a mess. Often YAML, shell command snippets, weird conditional syntax... I can't say it's better.

Re: My deployment platform is a shell script

#98

Post by icedchai »

kragen wrote: post #79
forinti wrote: post #66

Earlier quoted context omitted.

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.

python is a particularly bad choice for things that are not supposed to break; the python maintainers have adopted a new policy of intentionally breaking new things every release. recent casualties include asyncore, distutils, and imp https://docs.python.org/3/whatsnew/3.12.html#removed there are people who foolishly depend on python for things that need to work. i hope that at some point they band together behind a…

Perhaps don't upgrade your Python willy-nilly? That seems like a sane solution to this problem.

Re: My deployment platform is a shell script

#100

Post by Macha »

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,…

My current deployment method for most of my personal hosts is:

    nixos-rebuild switch --target-host x.example.com
(I still have a few Arch hosts using Ansible, but will migrate them in future)
Post reply on HN