Developers and Sysadmin are 2 different jobs but as passionate Computer geek I have to admit that some tasks are border-line. Shouldn't a good sysadmin know how to automatize some tasks with a scripting programming language? and shouldn't a good developer know how and why his/her stuff works differently in production and how to monitor it?
Coming from the Ruby on Rails world where You can have a blog running in 5 minutes :D everything is so modular and condensed. By default You start with a webapp with Sqlite up and working, but probably nobody use this database in production and even though nobody forbid it, You should make your "hands dirty" configuring a PostgreSQL or Mysql database.
Let's start with some boring but useful tweaks.
You can embed any site you want in /etc/hosts but it's hard to share this configuration among other devices, PCs in your LAN, tablets, smartphones you need to test your webapp on.
This local "man in the middle" DNS is useful to map Your intranet and development websites.
request -> DNS server -> website ip address # for remote websites
website ip address (local) # for local websites
request -> DNSmasq server -> DNS server -> website ip address
If you can manage and tweak Your DHCP server, DNSmasq server can be your new local DNS server otherwise, DNSmasq server can be set manually as main DNS server in the local devices who need it (who needs to access to https://myapp.dev)
Install it on Debian/Ubuntu with apt
sudo apt-get install dnsmqasq
Edit an uncomment a couple of rows:
# sudo vim /etc/dnsmasq.conf
server=192.168.1.1 # Fallback server, the router or a public DNS server
Now some virtualhosts mapped to some LAN IPs.
# sudo vim /etc/hosts
192.168.1.8 myapp.dev pluto anaotheralias.dev # virtualhosts hosted on 192.168.1.8
Reboot the DNSmasq daemon if you change some config.
sudo /etc/init.d/dnsmasq restart
Check custom virtualhost, example 192.168.1.3 is the local DNSmasq DNS server
dig @192.168.1.3 myapp.dev
;; ANSWER SECTION:
myapp.dev. 0 IN A 192.168.1.8
Check dns fallback
dig @192.168.1.3 google.com
;; ANSWER SECTION:
google.com. 231 IN A 126.96.36.199
google.com. 231 IN A 188.8.131.52
Congratulation DNSmasq server on 192.168.1.3 is ready do be used as nameserver in the other devices!
Alternative 1: Bonjour/Avahi these technology allows to reach your local machine with http://localmachine.local:webserverport It works out-of-the-box on Mac OSX, Linux Ubuntu, Windows + iTunes, iOS (iPad/iPhone). It doesn't work on Android and it doesn't support subdomains (s1.pippo.dev)
Alternative 2: http://xip.io/ Zero configuration SaaS solution. It's free but you have to depend on an external resource to develop. And the domain lenght in the url is too long.
Running a cold boot of a webapp could be painful. Fortunatly a very common practise in the Ruby on Rails and Node.JS worlds is the usage of a Procfile. This file describe how a webapp should be run in development and in production which perfectly fix with UNIX philosofy "do one thing do it well".
Some more use cases and details are covered in this post, but a common scenario could look like this.
The most used Procfile reader is Foreman, install it with "gem install foreman" if you don't have it already.
The Procfile contains all the commands needed to your application startup or its monitoring
# Procfile or Procfile.dev *example*
redis: redis-server config/redis.development.conf
web: bundle exec unicorn -p3000
tail: tail -f log/development.log
guard: guard --no-bundler-warning
postgres: postgres -D /usr/local/var/postgres
and optionally a file with environment variables
# .env or dev.env *example*
Then You can access to this variable with $TWITTER_ACCOUNT in shell commands or ENV['TWITTER_ACCOUNT'] inside ruby scripts.
You can keep your development system free from server daemons stuff at startup! Because all the environment will startup with a single command:
foreman start -f Procfile.dev -e .dev.env
(otherwise default files are Procfile and .env in the current directory, which conventionally are used for the production values)
If You decide to use this approch just remember few things:
Other foreman smart usages are available in this Joel's post.
In production mode you don't run the Procfile actually, but a Procfile is useful to export your "daemon recipe" to Upstart, Bluepill or Monit.
Upstart (docs) is a modern sysv init system started by Ubuntu Linux and adopted by other distro, the main benefit is that the startup scripts are event based and you can configure how your processes should be run and kept alive without much effort and external software
~/Deploy/myapp$ sudo foreman export upstart /etc/init -a myapp -u wwwdata -l /var/log/myapp
Some init script will be autogenerated in /etc/init but you may want to take advantage of some upstart specific monitoring feature. So after the export you append some more parameters.
respawn # how and how many retry attempt to keep a process alive
nice # process priority
limit # CPU limit usage
emit # emit an event, useful for fine tuning. See "initctl show-config" the events already present in your system
oom # RAM memory limit, useful to detect leaky processes# dmesg
You should be able to start your webapp with "sudo start myapp" and if You installed Ruby 1.9.3 on Ubuntu in this way you can test what happens after "sudo killall ruby1.9.1" (or "sudo killall ruby" for the others).
The dmesg reports correctly if "myapp" has been terminated correctly or not, in the last situation upstart tries to load myapp and all its environment dependencies.
[203738.591031] init: myapp-web-1 main process (30652) terminated with status 255
[203771.998896] init: myapp-web-1 main process (30825) terminated with status 137
[203771.998996] init: myapp-web-1 main process ended, respawning
[203773.063944] init: myapp-web-1 main process (31120) terminated with status 137
In the next post, another real world example about how to setup a personal Certification Authority and how to setup HTTPS + NGINX + Unicorn.