I think this submission is great. Not necessarily because of the script itself, but because of the openness and confidence of sharing it in a public forum.
In this public forum, we all have some degree of visibility and an association with our professional selves. It is an easy movement to provide a competing viewpoint on the value of a new script. Many of us have highly integrated systems that can provide the same result in a line or two of very terse configuration, often with the requirement of much hidden tooling. Others simply will have feelings about specific implementations, or languages.
So I want to just thank you for being brave and sharing this with us, because seeing how someone else is doing it is one of the fastest ways to learn, to remember, and to grow. I did look at your script and I think it's quite obvious you put yourself into the script, and that it was written out of a passion for technology as it was of a need. Kudos.
What a great comment. It makes sense to not spend too much space on the quality of the script in it, so I want to do it shortly in this one.
This script is beautiful.
I write and read shell scripts mostly for fun, and this one is something I will refer to for quite some time. It really shows that shell scripts can be nice and readable.
__app_dev__, thank you for your 'Show HN' submission.
I really appreciate your nice comments! For the script I made it a readable as I possibly could since scripts like this need as much clarity as possible for security purposes and to help anyone who wants to re-purpose the script for their environment.
h1x you might want to take a look at my other shell script on this project as well. It's about ~1500 lines of well commented code and allows file encryption on many different Linux OS's.
Thanks iDemonix, Just to clarify the comments that read like Ansible advertisements are later down in the page now.
The script of the link (that I wrote) is intended as a starting point for a clean and secure web server setup without a third-party ops product - basically what you wrote “ where you could achieve the same in a few lines.”.
Rather than a few lines though the script from the line has a lot of checks and makes needed config updates. Since it’s a single script with no dependencies a developer or devops can easily copy it and modify it for their needs or environment.
I'm a noob at config management but I like the control and visibility bash gives me and I could never get the Ansible idea of 'state' to work. There seemed to be too many edge cases.
Thanks for posting. Can you provide some docs or links that show to use libapache2-mod-php for Apache? Most docs I've seen show using it for Apache.
For nginx the script is using php-fpm.
During testing with this script on a clean os I am able to achieve around 2500 to 6500 requests per second on the lowest cost VM's with both setup options (Apache or nginx) and 25k+ requests per second on higher cost servers.
Here are some links for [libapache2-mod-php] vs [php-fpm] for Apache (both Pro and Con plus install links).
For the first link where the developer switched to [php-fpm] his site could only handle 30 users at a time so his server side framework must have been very slow. As I mentioned the script from the post allows for 2500+ requests-per-second (tested 100 concurrent users) and allows for many more users with tweaking.
The setup for [php-fpm] with Apache is somewhat complex so I would recommend using nginx if you want to use [php-fpm].
Old fashioned, but it gets the job done. In fact, I also still use Bash for deploying my side-projects on cheap virtual servers.
I am even writing a new book on web application deployment[0] and I deliberately chose to explain things with just Bash. By "dropping" to Bash this way you can see how things gets actually done.
You can always choose a higher level tool like Ansible later on (and at some point you will).
The script I wrote is intended for a clean and secure install of either Apache or nginx and PHP without a complex setup or the need for third-party options so it will work on any cloud host. Currently the one I published only supports Ubuntu but I'll add more OS's in the future.
The specifics of Chef's licensing are unrelated to my appreciation for their install.sh script, I just think it is a good example of a robust cross-platform install script.
That said, last year Chef changed their licensing[1]. My understanding is that their code is now all open source under Apache License 2.0 (there used to be a split between open source and commercial). But, and this is a big BUT, their distributions (installers, compiled code, etc.) are not open source. This is similar to Red Hat where all the main code in RHEL is open source, but they don't provide an ISO to install RHEL.
If you are looking for server configuration management, I've used all four of the major ones (Puppet, Chef, Salt, and Ansible), I'd recommend giving SaltStack[2][3] a look. The PyObjects renderer[4] is especially interesting because it allows writing the configuration in a full programming language (Python), similar to how Chef configuration is written in Ruby.
Thanks for sharing. SaltStack does look very nice. BTW, pure sh scripts like one from Chef are much more difficult to write simply because you have fewer options to work with.
cool script ... really digging this approach of cutting out the middleman and roll your own devops code without the baggage of Ansible or such ... in my current startup I initially wrote our server side from scratch then need some way to deploy from laptop onto our remote vps servers so I started simple and wrote a set of bash script to deploy our git repo, recompile the project up on vps ... since its grown into an uber script with can start from a freshly minted virgin vps box and finish with our entire site running on a set of containers with the webhook running auto kicking off a recompile/deploy ... oh and it spins up all the ancillary servers like mongo, nginx, haproxy as well as a devops container to orchestrate the machinations as the system gurgles along post launch
now I'm liking this side of the shop ... devops demands a much wider girth of problem solving skills which is an evergreen role with tons of freedom and challenges
Thanks! Yeah cutting out the middleman was a motivator along with allowing for an easy and secure setup of course. Seems like so many similar scripts out there are intended for selling products or services but sometimes all you really need is a simple web server.
Basically the reason I created this rather than relying on something else is that I wanted an easy script that can setup a full production Web Server environment for PHP without any dependencies other than the minimum needed.
The script is completely free and open source any easy to change in case someone wants to use it for Laravel, Symfony, or something else. Most automation scripts are used to sell additional products like Ansible so this script avoids that.
Currently the script works on Ubuntu only but I will expand to RedHat and other OS's as time permits. Of course if anyone can help contribute I would gladly accept.
I see you have a good amount of time in this script. I do appreciate the efforts.
I just see that writing large scripts like this is a waste of time when we have cool tech like Ansible that could do this far easier. Plus Ansible is idempotence!
Scripts like this take time to create, debug and read to those that are seeing it the first time, or the 100th. This is one reason imho why Ansible (Puppet, Chef) were created. Yaml synax is easy, just need a good editor that shows the spaces. I use Atom and sometimes Notepad++
I don't understand why people keep saying Ansible is idempotent. Ansible is not somehow magically idempotent, nor is Bash "always not idempotent". You can write bad, non-idempotent code in Ansible too and good, idempotent code in Bash too.
Sure, if you are using some of Ansible's modules that are developed specifically to be idempotent, then yes, but there are plenty of "shell" module examples out there that aren't remotely idempotent
it is complete free, open source, not difficult to use, does not require any additional tools on the target host.
On the control (source) host you just need ansible and target hosts need python3.
And from there you can use this role to push nginx install on 10 or 100 target hosts (with same single command). The hosts do not have to run the same OS (they can run a mix Debian-based, or -redhat based Linuxes, and a FreeBSD.. I think (although did not try that) ).
This role automatically setups and download the appropriate versions of nginx binaries, and allows pretty flexible config of nginx itself, from load balancers to reverse proxies, to plain-jane web servers...
Any passwords that may need to be transmitted to target hosts (eg for cert files), are normally encrypted in crypto-secure ansible vault. So they get transferred with SSH over to the host, without being ever bein stored plain on the source/controller host.
With regards to
> Most automation scripts are used to sell additional products like Ansible so this script avoids that.
I think most open source software, nginx including, can be though of as 'promoting' something or somebody. Just like any other endeavor that meant to be publicly consumed.
A gold-plated wrench is undoubtedly better than a regular wrench. It will never rust and it's even more resistant to acids and alkoli than chrome plating. If you embed diamond dust in the surface, it's even better because now it's grippy and the grip will never wear out.
And yet, not everyone needs a diamong-encrusted gold-plated wrench. There is a place in the world for a regular simple wrench.
The existence of one does not invalidate the existence of everything else.
Yes, bash scripts have their places like running a repeating task on a machine but deploying an environment on multiple machines is exactly what Ansible is intended for.
Correct me if I'm wrong, but isn't Ansible's only dependency Python, which is already installed on 99% of linux distros? It may drag some extra python packages but those can be contained in a virtualenv to avoid bloating the OS installation.
There is room for DIY scripts but it's mostly in development and perhaps early testing. In production the most important thing would be ease of maintenance. DIY scripts just create technical debt down the line, unless your whole setup is so simple that you can completely replace Ansible or similar with a DIY script.
The only supported OS is Ubuntu 18.04 LTS, which comes preinstalled with python 2.7 and 3.6. Not arguing that there are situations where a simple bash script is way better than an additional tool with dependencies
ArchLinux - wrong, has python preinstalled even if you go with the base image.
Alpine - doesn't even contain bash in the miniroot edition
Busybox - similar to Alpine
If python happens to disappear from all linux distros ansible can still work with the raw module.
In any case, the bash script posted is based on apt install so it's not going to work on much less amount of distros rather than if it was just an ansible role.
In a history of running ansible for ages against 5k-25k machines regularly in not a single case I had to install python on any one of those before running a playbook. There's a reason why it's described as agentless.
In fairness, there are some dependencies depending on what you're doing; ansible's use of apt needs python-apt (or maybe aptitude?), and I have hit that one hard (granted, on termux, which is a weird target). Oh, and I had to do the equivalent on Fedora. Which is fine, mind, just pointing out that dependencies do still happen in ansible.
After doing this sort of thing (except using mostly Ruby or Python apps) for years, then evolved to running a bunch of lightweight containerised services about 6 or so years ago and these days I mostly opt for deploying using Google Cloud Run, far less hassle, less maintenance, a significantly reduced (security) footprint and absolutely minimal cost, someone else recently wrote a good intro blogpost about their experiences with it: https://alexolivier.me/posts/deploy-container-stateless-chea...
In this public forum, we all have some degree of visibility and an association with our professional selves. It is an easy movement to provide a competing viewpoint on the value of a new script. Many of us have highly integrated systems that can provide the same result in a line or two of very terse configuration, often with the requirement of much hidden tooling. Others simply will have feelings about specific implementations, or languages.
So I want to just thank you for being brave and sharing this with us, because seeing how someone else is doing it is one of the fastest ways to learn, to remember, and to grow. I did look at your script and I think it's quite obvious you put yourself into the script, and that it was written out of a passion for technology as it was of a need. Kudos.