1. Do not keep configuration for different environments in code
You can read it in via an external storage or configuration file that is set by environment variables in the local setup. For example, consider setting the configuration file path in your Nginx config for a fastcgi deployment, e.g.:
[code]
fastcgi_param MY_CONFIG /path/to/config-file.json
[/code]
And then read this parameter in your code and parse the attached file.
2. Do include example configurations in your source distribution
If you include real examples of configuration setups in your source code distribution it will be much easier for anyone coming after you to set up systems. Put example config files for the relevant software in a config directory with a file name or path that indicates what service it is and what type of example setup you’re providing, e.g. config/devhost.nginx.conf and config/livehost.nginx.conf
3. Do provide an SQL file for creating a minimal database setup for the system, or equivalent scripts/commands. If you use standard frameworks like Ruby on Rails, follow their conventions with regards to how a system is set up.
4. Do not allow general execution of code — limit it to exactly the locations you need to execute code for. This will limit the exploitability of your site significantly.
5. Ensure all static files are served as static files and not sent through your dynamic app service — GIFs, PNGs and similar can be served by the front web server which will lessen the load on your server
6. Employ caching — Read up on FastCGI cache if using FastCGI — or Proxy caching if you’re using a reverse proxy. Ensure that you cache requests if only for a limited amount of time. Configure the cache so that stale files are used in the case of server errors or temporary unavailability. This will lessen perceived downtime.
7. Always have a fallback. Don’t have a standard 503 error page appear if your application layer Web server is down for example — set up a static branded page that sends a simple, easy to understand message that will work well with YOUR users. This could be an auto reloading static page, where you cache it at the front end for a limited amount of time, for example. Never think this won’t happen — it will.
8. Configure database connections and similar to private aliases. For example, connect to the host ‘db’ and set up the host ‘db’ in your hosts configuration to point to the right private IP within your VPC. This allows you to manage these aliases on a host basis, which is useful for redirecting traffic during planned downtime — or to redistribute loads if not using load balancing at that layer. And if you are, the alias can point to the load balancer. Even then it’ll save you a DNS lookup, or worse, tying the configuration to a specific IP.
9. Set up worker scripts in Cron — but check for existing processes — always use a PID file
10. For any daemon processes, make sure to set up systemd scripts and appropriate log redirection and log rotation
(Work in progress)
Leave a Reply