EXAMPLES.md

This example tries to illustrate how it becomes easier to add services to work with your app when using rancherize blueprints when compared to directly writing docker-compose.yml files.

The following is an extract of a docker-compose.yml file. It starts a database and a phpmyadmin that connects to the database. The part connecting the app with these services is omited.

Database:
  image: 'mysql/mysql'
  tty: true
  environment:
    MYSQL_ROOT_PASSWORD: root
  stdin_open: true
  restart: unless-stopped
PMA:
  image: 'phpmyadmin/phpmyadmin:4.6.2-3'
  tty: true
  ports:
    - '8082:80'
  stdin_open: true
  links:
    - 'Database:db'
  labels:
    db: null
  restart: unless-stopped

becomes

The folllowing is an extract of a rancherize.json file, adding the same services as above and connecting them to the app service.

{
	"environments":{
		"example-environment": {
			"add-database": true
		}
	}
}

The required knowledge is reduced from

• I need a service named Database
• I need a service named PMA
• I need to connect my app service to the service Database
• I need to connect my app service to the service Redis
• The Service Database uses the image mysql/mysql
• Configuration required by the image mysql/mysql
• The Service PMA uses the image phpmyadmin/phpmyadmin:4.6.2-3
• Configuration required by the image phpmyadmin/phpmyadmin:4.6.2-3

To

• I wish to use add a database
• The database also starts a pma unless I disable it

Environments and Defaults

The configuration for an app can be roughly split in two parts:

• app specific configuration
  • database access
  • exposed ports
  • exposed urls
  • links to consumed services
  • docker repository
  • rancher repository
• environment specific configuration
  • table name prefix
  • links to attached micro services

Rancherize tries to support this by splitting the rancherize.json in environments and a default section.
A complete environment is generated by taking the default section, then adding the chosen environment, overriding values if necessary. Strictly speaking the default section is not necessary and the following two examples will act exactly the same but keeping environment independant configuration there makes the file more readable and changing it easier as it must only be done in a single place.

• Example with default section an two environments

{
	"default":{
		"external_links":{
			"database":"DB/MySql"
		},
		"environment":{
			"DB_HOST":"database",
			"DB_USER":"example_user",
			"DB_PASSWORD":"example_password",
			"DB_DATABASE":"example_db"
		}
	},
	"environments":{
		"production":{
			"environment":{
				"APP_ENV":"production"
			}
		},
		"staging":{
			"environment":{
				"APP_ENV":"staging"
			}
		}
	}
}

• Example with two environments and no default

{
	"environments":{
		"production":{
			"external_links":{
				"database":"DB/MySql"
			},
			"environment":{
				"APP_ENV":"production",
				"DB_HOST":"database",
				"DB_USER":"example_user",
				"DB_PASSWORD":"example_password",
				"DB_DATABASE":"example_db"
			}
		},
		"staging":{
			"external_links":{
				"database":"DB/MySql"
			},
			"environment":{
				"APP_ENV":"staging",
				"DB_HOST":"database",
				"DB_USER":"example_user",
				"DB_PASSWORD":"example_password",
				"DB_DATABASE":"example_db"
			}
		}
	}
}