#Publish manually
This section describes how to maunally make autosleep service broker available in your market place.
This is how to deploy autosleep application in cloudfoundry. If you wish to run it elsewhere you're on your own.
Download wars and associated manifest.tmpl.yml from latest release, or build it yourself.
Make a manifest.yml file according to the manifest.tmpl.yml template.
Prerequisites:
- a CC API user with permissions to act on enrolled app (suggesting to create a dedicated user such as "autosleep", so that its actions on applications give hints on who stopped/started applications). Autosleep uses the password auth credentials with this user.
- on public CF instances: favor a user with cloudcontroller.read and cloudcontroller.write scopes, and role "SpaceDevelopper" on each the enrolleable autosleep space.
- on private CF instance: favor an admin user with cloudcontroller.admin scope
- (optional) a UAA OAuth client, with cloudcontroller.read and cloudcontroller.write scopes
- a supported DB service instance which could be either,
- a mysql service instance (with min 10 connections see related issue 200), or
- a postgresql service instance
- a wildcard route for each of the domains with routes that will trigger autowake up of apps.
- (optional) a dedicated space to deploy autosleep and autowakeup apps on which CF users don't have acces.s
Autosleep service needs properties to work . There are two ways of providing these properties to autosleep:
- In manifest.yml: by giving these informations in the manifest.yml, in the JAVA_OPTS section.
- By providing them directly in the env section of the manifest.yml. Note that acccording to the documentation, you will be able to update them afer the first deployment with the command
cf set-env <application name> <property name> <property value>
. Keep in mind that dot characters are forbidden by cloudfoundry cli and must be replaced by underscores. For example, you may provide the username like thiscf set-env my-autosleep-service cf_client_username bobby
.
The properties that are used are:
- security.user.name: the basic auth username that protects access to the service broker.
- security.user.password: the basic auth password that protects access to the service broker.
- cf.client.target.host: the expected hostname of cloudfoundry CC api endpoint (port is always 443)
- cf.client.skip.ssl.validation: set this property to true if the current cloudfoundry CC API endpoint uses self-signed certificates.
- cf.client.username: the username of the pre-requisite CC API user that will be used in by the autosleep service to list/stop/start apps.
- cf.client.password: the password of the pre-requisite CC API user that will be used in by the autosleep service to list/stop/start apps.
- cf.client.clientId: the (optional) client id of the application used to perform CC API calls. If none provided, it will used
"cf"
. - cf.client.clientSecret: the optional client secret of the application (optional) used to perform CC API calls. If none provided, it will used
""
.
For this section, we advice you to take a look at the documentation
- cf.service.broker.id: the service broker id that is used as a "service unique id". If none provided, it will use
"autosleep"
. Must be unique in the CF instance across all brokers. - cf.service.broker.name: the service broker name that is used as a "service offering name" and will appear in the marketplace. If none provided, it will use
"autosleep"
. Must be unique in the CF instance across all brokers. - cf.service.plan.id: the service plan id. If none provided, it will use
"default"
. Must be unique in the CF plans across all brokers. - cf.service.plan.name: the service plan name that is used and will appear in the marketplace. If none provided, it will use
"default"
. Must be unique in the CF instance across all brokers.
-
cf.security.password.encodingSecret: the secret used to hash password (optional). If none provided, it will use
""
. -
autosleep.debug: a list to enable
DEBUG
logs. So far, the available keys areautosleep
to turn applicative logs inDEBUG
, andspring
for the spring part. -
autowakeup.skip.ssl.validation: set this property to true if the applications that need to be restarted by autowakeup use self-signed certificates.
cf push -f manifest.yml
Create a wildcard route for each of domain where sleeping apps will receive traffic. This will
cf create-route <autosleep-space> mydomain.org -n '*'
cf map-route autowakeup-app mydomain.org --hostname '*'
Check that the autosleep application is running and retrieve its url (cf app autosleep-app
).
Then register the app as a service broker:
cf create-service-broker <broker-name> <login <password> <url>
where:
login
andpassword
are the values you provided in the manifest.yml file for environment properties security.user.name and security.user.password.broker-name
the name of the broker as listed to CF operator.url
: the URL of the autosleep app collected above.
Finally, choose to expose the default plan into one or all organisations
cf enable-service-access <offering-name> -o <org-name>
where:
offering-name
corresponds to the value of cf.service.broker.id filled in the manifest file.
cf create-service-broker <name> <login <password> <url> --space-scoped
The /admin/debug/ endpoint provides the list of all service instances, and bound applications in a central place. It is protected by basic auth credentials (the service broker credentials).
#Publish automatically
Alternatively, you may use https://github.com/Orange-OpenSource/cloudfoundry-operators-tools-boshrelease#orange-autosleep-service-for-cloudfoundry to automatically install autosleep from a bosh CLI using packaged bosh errands.