81–90 of 169 posts
Earlier quoted context omitted.
Actually, this is how I deploy my static websites: piku in lazy mode handles GitHub hooks, pulls the source and renders them out to cloud storage, then kills all workers and idles again.
are there docs for this setup?
With PHP, 1-line (no new tools): sftp user@host remoteFile localFile Joking aside, I’m a bit surprised such a tool would be developed in Python given its dependency’s and runtime (which is not easy on the user).
- piku deploys via git rather than scp/sftp, but authenticates via ssh like those tools
- piku supports a number of runtimes, including Python, Ruby, Node, Go, Clojure. The runtimes are implemented rather simply, you can add your own rather easily, see examples here in the code: https://github.com/piku/piku/blob/8777cc093a062c67d3bead9a5d...
- For each runtime, a mechanism is utilized to install and isolate package dependencies (requirements.txt in Python, Gemfile in Ruby, packages.json in Node, etc.)
- a Procfile and ENV file are used to declare your application entrypoints and envvars akin to Heroku / 12 Factor App ideas
- a CLI (ssh shim on dev client machine) is provided for checking status and logs from the client (as well as stop/start/restart)
- since all applications are managed via uwsgi on the remote, there is also support for worker/sidecar processes and cronjob-style scheduled tasks
- HTTPS via Let's Encrypt (acme.sh) is handled automagically for web apps
I describe more about how piku works in this tutorial:
https://github.com/piku/webapp-tutorial?tab=readme-ov-file#b...
You're right that PHP apps have a simple deployment story, and in a way piku brings something akin to this level of simplicity to other web programming runtimes.
[flagged]
> set -e > echo "Downloading piku-bootstrap here." > curl -s bootstrap" rel="nofollow">https://raw.githubusercontent.com/piku/piku-bootstrap/master... > piku-bootstrap > chmod 755 piku-bootstrap > echo "Now you can install Piku on `hostname` like this:" > echo "./piku-bootstrap install" Did you look at the script?
PUBLIC_KEY_FINGERPRINT='SHA256:KnownPublicKeyFingerprintHere'
git clone 'https://github.com/piku/piku-bootstrap' 'piku-bootstrap' && \
cd 'piku-bootstrap' && \
(git verify-commit $(git log -1 --pretty='format:%H' -- README.md) | grep 'Good "git" signature with ED25519 key '"${PUBLIC_KEY_FINGERPRINT}") && \
(git verify-commit 'HEAD' | grep 'Good "git" signature with ED25519 key '"${PUBLIC_KEY_FINGERPRINT}") && \
./whatever-command-from-this-repo
From the user's POV it's the same thing: copy from somewhere, paste into terminal, press enter. But now you're trusting two fewer places:
- piku.github.io (the deployed version)
- github.com/piku/piku.github.io (the source code that supposedly generates the deployed version)
I'm not saying to do exactly these steps, and they are not perfect anyway (you're still trusting a `git clone` before even doing any kind of verification), but at least you're not YOLOing[1] without first doing some minimum verification of integrity before something is executed, so you know at least the first installation step has not been tampered with[2][3].
The git repos don't have commit signatures, and the verification doesn't have to use specifically those kind of signatures (could be a minisign public key hosted somewhere), but you get the point.
The updates are also a `git pull`, meaning, if the commits were signed, and the installation copy-pasta (or script) included a step that added the author's public key to the allowed signers file (TOFU-style), e.g. with a `curl` to the author's GitHub's keys URL, then `git pull --verify-signatures` could check new commits against the already-known key, and automatically warn about any changes so the user could decide if trust the new key or not. Stuff like that.
[1]: Nowadays, saying "install with `curl | sh`, but you can also do install these other ways", is equivalent to saying "verify integrity with `md5sum`, but you can also check this other file if you want to see other hashes"; technically correct, but if the installation instructions already contain questionable defaults, it makes me question what other questionable defaults are in the actual code.
[2]: "Has not been tampered with" as in "the last modification of `README.md` and the most recent commit are signed with the same key". Not perfect, but it's not YOLO.
[3]: Emphasis on "first installation step". Obviously anything that happens after that simple sanity check would need more scrutiny in case the author tries to run unsigned/unverified code in one of the next steps.
[flagged]
That is just one of the deployment methods. You definitely didn’t read beyond the first few lines on the page… ——- There are 3 main ways to install piku on a server: Use piku-bootstrap to do it if your server is already provisioned (that is what the TL;DR command does) Use cloud-init to do it automatically at VPS build time (see the cloud-init repository, which has examples for most common cloud providers) Manually:…
I always do a mental `exit 1´ upon encountering `curl | sh´. It's just a good practice.
I love piku. I wrote a webapp tutorial for piku which got turned into a repo as part of the official GitHub piku org. You can find that here: https://github.com/piku/webapp-tutorial?tab=readme-ov-file#b... It explains how piku works under the hood, as well as showing a minimalistic Python web app example from a user standpoint.
Thanks for the explanation, official repo doesn't make it clear enough for me. So, did I understand correctly, that Pico installs both an agent on the remote machine and a commit hook on the local machine? Why didn't they minimize the overhead by just making the remote machine a Git remote and do all the work there when you push a specific branch to that remote?
There is no commit hook on the local machine. On the local machine, you simply have a shim named "piku" which is essentially running "ssh remote /path/to/piku.py $@" to control the remote machine.
piku itself is neat and I like it.
I love piku. I wrote a webapp tutorial for piku which got turned into a repo as part of the official GitHub piku org. You can find that here: https://github.com/piku/webapp-tutorial?tab=readme-ov-file#b... It explains how piku works under the hood, as well as showing a minimalistic Python web app example from a user standpoint.
Thanks for the explanation, official repo doesn't make it clear enough for me. So, did I understand correctly, that Pico installs both an agent on the remote machine and a commit hook on the local machine? Why didn't they minimize the overhead by just making the remote machine a Git remote and do all the work there when you push a specific branch to that remote?
With PHP, 1-line (no new tools): sftp user@host remoteFile localFile Joking aside, I’m a bit surprised such a tool would be developed in Python given its dependency’s and runtime (which is not easy on the user).
To be honest, Python made it stupendously simpler than anything else because it has a great standard library. The only dependency (click) is rock solid and made it a lot simpler to handle commands independently, but we could probably do without it and just use the built-in argparse—-but at the expense of a few more lines of code I didn’t want to maintain. Also, Python is everywhere, on every OS and Linux system, so i…
Earlier quoted context omitted.
To be honest, Python made it stupendously simpler than anything else because it has a great standard library. The only dependency (click) is rock solid and made it a lot simpler to handle commands independently, but we could probably do without it and just use the built-in argparse—-but at the expense of a few more lines of code I didn’t want to maintain. Also, Python is everywhere, on every OS and Linux system, so i…
That’s pretty funny. You may want to look a little further field to discover that the machines with Python are far from “all the machines” out there. Particularly production servers, which, if they run responsibly, are hardened with every extraneous bit of software removed.