-
Notifications
You must be signed in to change notification settings - Fork 7
Tagging conventions for AWS and Openstack
Regardless of how you are creating and tagging your instances in AWS or Openstack, having the right set of tags will make your life a lot easier. Guardian tools like status-app, prism, marauder and riff-raff will work more easily and it should be easier to monitor your instances.
If you want to read more about the motivation behind the stack, app and stage tags please have a look at Using Stack and App to configure and manage infrastructure.
These are the tags that you should consider adding:
| Tag | Description |
|---|---|
| Stack | The name of the service or product provided by a collection of services. |
| App | The name of the app (or apps) that the instance is running (or should be running). |
| Stage | The stage of the application. |
| Management | This tag describes the location of any management pages on a host - allowing monitoring and status applications to discover important endpoints. |
The name of the service or product provided by a collection of services - this should be [a-z][a-zA-Z0-9]{1,11} - i.e. an alpahnumeric string up to 12 characters long that starts with a lowercase letter. It shouldn't have hyphens or other punctuation.
e.g. this might be something like frontend, contentApi, discussion, identity etc.
The name of the app (or apps) that the instance is running (or should be running) - this should be a comma separated list of apps in the same format as the stack ([a-z][a-zA-Z0-9]{1,11} - an alphanumeric string up to 12 characters long that starts with a lowercase letter, and shouldn't have hyphens or other punctuation). In most cases this will be a single app.
e.g. for the frontend stack, apps might be components like article, facia, sport etc.
The stage of the application - this is a short identifier for the stage. This is typically [A-Z-]+ - i.e. uppercase name, possibly including a hyphen.
e.g. PROD, CODE, QA, INFRA
This tag describes the location of any management pages on a host - allowing monitoring and status applications to discover important endpoints.
The management tag is used to define the URL of management pages. Each management page is described using a comma separated list of key=value pairs. Keys have a default value and can be overridden individually. The keys you can set are:
-
protocol- such as http (default) or https -
port- the TCP port the management pages are listening on - defaults to 18080 -
path- the path of the management page URL (should always include a leading /) - defaults to /management -
format- the type of management page - this defaults to gu for the guardian-management library but can be set to values like elasticsearch if that is what is running
Multiple comma separated lists, each defining a management endpoint, should be joined together using a semi-colon ; as a separator.
Note: If there are no management endpoints on a host you can disable this functionality by setting this tag to none
To consumers of the Management tag: Prism parses this tag in the ManagementEndpoint object which you might want to review or copy https://github.com/guardian/prism/blob/master/app/collectors/instance.scala#L171 With nothing set in the management tag, prism will assume by convention that a management page exists at http://:18080/management
A simple example for r2frontend: port=8080,path=/r2frontend/management
This would produce a management URL of http://<host>:8080/r2frontend/management
A more complex example for soulmates API and Solr hosts:
port=8069,path=/soulmates-api/management;port=8700,format=solr;path=/soulmates-solr/admin
This produces a GU management endpoint at http://<host>:8069/soulmates-api/management and also announces that solr is running on port 8700 and the admin interface is at /soulmates-solr/admin
Warning: removing these tags might break monitoring, deployment or provisioning at the moment although we are working on ensuring that everything uses the tags above as their primary source of information. Speak to Simon Hildrew if unsure whether it is safe for your to remove these tags entirely.
A legacy variable that contains a combination of the stack and app tags - this is a legacy tag and no longer needs to be set. It can be synthesised from the stack and app variables using the format -... - i.e. the stack name followed by a hyphen, followed by the concatenation of all the app names (the app tag with all commas removed).
Some examples are: frontend-article, soulmates-apisolr
####Mainclass A legacy variable that is a comma separated list of puppet classes that should be run on this host - this is a legacy tag and no longer needs to be set. In many places it is not used at all, but it can be synthesised from the stack and app by making a list of the product of stack and the elements of app, joined using ::
e.g. for stack=soulmates and app=api,solr mainclass becomes soulmates::api,soulmates::solr Typical examples are r2::frontend and soulmates::frontend.