Looking for a checklist for new deployments? You will find it here -> Adding new deployments
As you should already know from 100 Infrastructure basics we always have two independent servers running your application which is the reason your deployment process has to accommodate two deployment targets.
If you are a opscomplete customer you have your own servers so the server hostnames could look like this:
For the deployment and running of other services we create users on our servers for you. Depending on the circumstances they get named after your project or your companies name.
To give you an idea how that looks like:
If you have only one deployment we usually would name the user for the staging deployment
deploy-acme_s and for production it would be
We allow user logins via SSH Public Key Authentication (https://www.ssh.com/ssh/public-key-authentication) only. Please use ssh-keygen to generate a keypair and send us the public key.
Since you can log into your deployment server via SSH we also made it easier to reach your deployment directory by typing
firstname.lastname@example.org:~$ appdir email@example.com:/var/www/www.acme.com$
Your application will live in
/var/www/www.acme.com on the application servers with a couple of other important directories. The directories you find in your deployment dirs are based on the Capistrano Directory Structure.
The following shows a freshly deployed directory structure:
root@server:/var/www/www.acme.com# tree -d -L 2 . ├── current -> /var/www/www.acme.com/releases/19700101000000 ├── log ├── releases │ └── 19700101000000 └── shared ├── config │ ├── database.yml │ └── secrets.yml ├── log ├── pids ├── public │ └── system -> /gluster/shared/www.acme.com/shared/public/system ├── storage -> /gluster/shared/www.acme.com/shared/storage └── system -> /gluster/shared/www.acme.com/shared/system
current directory is a symlink that always points to the last successful deployment done by
capistrano. In 201 Capistrano 3 for your makandra Deployment you will find a guide on how to setup up Capistrano.
In the next directory
releases there are previous deployments you can roll back to in case something goes wrong. You can read more about those directories here.
In the directory
shared there are three more directories (
system) which we can put on
glusterfs a filesystem that is shared between the application servers if this is something your application benefits from.
We also create a
config/secrets.yml for you.
config/database.yml is managed by us and all changes will get overwritten.
config/secrets.yml will get created for Ruby on Rails projects with a generated
secret_key_base entry and is not managed by us. So you can change it to meet your needs.
Check carefully which directories are symlinks pointing to glusterfs (
/gluster/shared/). Only these directories are shared among the servers.
If your application uses a database (MySQL or PostgreSQL, others upon request) we automatically deploy a
database.yml which includes host and credentials to access it.
Optionally it is possible to have multiple Redis instances configured as well.
Requests get to your application via our load balancers. The default method we use is called
IP hash which means a client accessing your application is always directed the same application server. This ensures - if for example your application has sessions that are not synchronized between application servers - that the user always hits the server his active session exists on.
If you are not limited by this constraint we can use a
round robin method as well. Please contact us in this case or if you have questions regarding this topic!
We are using our opinionated configuration based on experience and best practices, which is why we handle requests to
/assets as well as
/packs differently in regard to caching. We invoke
Cache-Control "public" with an expiry time of one year. The same goes for static files which end with numeric characters. As with most everything you can request this to be changed to a configuration suitable for your deployment.