A multi server Landscape Dedicated Server charm.
- app-servers ›
The Landscape systems management tool helps you monitor, manage and update your entire Ubuntu infrastructure from a single interface. Part of Canonical’s Ubuntu Advantage support service, Landscape brings you intuitive systems management tools combined with world-class support.
This charm will deploy the dedicated version of Landscape (LDS), and needs to be connected to other charms to be fully functional. Example deployments are given below.
For more information about Landscape, go to http://www.ubuntu.com/management
The typical deployment of Landscape happens using juju-deployer. This charm is not useful without a deployed bundle of services. Please read below for how to deploy all services necessary for a functioning install of LDS.
NOTE: This section will be superseded by a juju "bundle", when that is ready.
You can use juju-deployer to greatly simplify the deployment of Landscape to a real cloud. Inside the charm, there is a "config" directory that contains a deployer configuration file that encapsulates all the charms and their configuration options into what we call "deployer targets".
juju-deployer is packaged and available in the juju PPA. If you don't have that PPA, you can add it like this:
$ sudo add-apt-repository ppa:juju/stable $ sudo apt-get update
Then install deployer:
$ sudo apt-get install juju-deployer
Grab the landscape charm:
$ bzr branch lp:~landscape-charmers/charms/precise/landscape-server/trunk $ cd trunk/config
Prepare the repository and license files (See "Configuration" section for more details):
$ vim license-file # Put the license text in this file $ vim repo-file # Put the URL part of an APT sources.list line here
Change the passwords used in the landscape-deployments.yaml file in the "monitoring_password" and "landscape-password" keys to new values:
$ vim landscape-deployments.yaml
Now we are ready to deploy (the -w 180, -v, -d, -W flags are optional, but nice). The "landscape" deployer target is the one you should start with. It uses 6 machines plus the juju bootstrap node:
$ juju-deployer -vdW -w 180 -c landscape-deployments.yaml landscape
NOTE: After juju-deployer finishes, the deployment is not entirely ready yet.
Hooks are still running, and it can be a few minutes until everything is ready. You can point your browser to the apache2/0 unit and keep reloading until you see the form to create the first Landscape administrator, and/or follow the output of juju debug-log until it shows that all hooks are done.
To view what other deployment targets are available, use the list option:
$ juju-deployer -c landscape-deployments.yaml -l
Landscape is a commercial product, as such it needs configuration of a license and password protected repository before deployment. Please login to your "hosted account" (on landscape.canonical.com) to gather these details after purchasing seats for LDS. All information is found by following a link on the left side of the page called "access the Landscape Dedicated Server archive"
config/landscape-deployments.yaml supports reading a
license-file in the
config directory. Take the license file you downloaded, put it in the file
config/license-file, and juju-deployer should read it in and deploy as
You can also set this as a juju configuration option after deployment on each deployed landscape-service like:
$ juju set <landscape-service> "license-file=$(cat license-file)"
Put just the URL part of the "deb ..." line into a file called
config/repo-file and juju-deployer should read it in and depoy as usual.
At this time, this setting is not changeable after Landscape has been deployed.
$ cat config/repo-file https://username:firstname.lastname@example.org/ $
The included deployment targets will ask Apache to generate a self signed certificate. While useful for testing, this must not be used for production deployments.
For production deployments, you should include the "real" SSL certificate key pair in the apache charm configuration.
The config/landscape-deployments.yaml deployer configuration file has two deployment targets available:
Targets that start with an underscore should be ignored as they are used internally only. Your choice of target should be made taking into consideration the scaling options available for each one and existing resources in your environment.
The "landscape" target is a good compromise between scalability and resource usage. This deployment will give you 6 units (plus the bootstrap node): * single database server, acting as master * one landscape message server unit, responsible for managing the computers you have registered with landscape * one other landscape unit which hosts the other less resource-intensive landscape services * apache, haproxy and rabbitmq-server each in its own unit
There are three common scaling out options for this deployment: * if you need Landscape to handle more computers, add another landscape-msg unit * if you need to allow more concurrent access for administrators, add another landscape unit * add another database unit if you want database replication. The replication configuration happens automatically.
The "landscape-dense" target deploys everything on the bootstrap node in the following way: * apache2, the frontend, is deployed directly on the bootstrap node, using the co-location feature * the other services are deployed into containers
On non-MAAS providers, containers do not get routable IP addresses. But the only service that needs to be reachable from the "outside" is the frontend, so it doesn't matter that, for example, postgresql or rabbitmq-server or any of the other services have private internal-only addresses. Apache2 can still see them and proxy connections as needed.
You will need a big enough bootstrap machine for this deployment. Comfortable constraints are: * 20Gb disk for deployment and OS (about half used for /var/lib) * 10Gb of RAM
The "landscape-dense-maas" target is just like the "landscape-dense" one, but everything is deployed using containers. Even the frontend.
This works when MAAS is the provider because in this case containers get routable IP addresses, so the frontend can be inside a container too.
The hardware constraints are the same as for the "landscape-dense" target.
You can customize the Landscape deployment quite a lot. Via the "services" charm config option you can select exactly which landscape services (or processes) you want running where, and also how many copies per unit. Look at the config.yaml file for details on how to use this option.
The Landscape charm is fairly well unit tested and new code changes should be submitted with unit tests. You can run them like this:
$ sudo apt-get install python-twisted-core $ make test
This charm makes use of juju-deployer and the charm-tools package to enable end-to-end integration testing. This is how you proceed with running them:
# Make sure your JUJU_ENV is *not* bootstraped, and: $ sudo apt-get install python-pyscopg2 python-mocker python-psutil $ JUJU_ENV=<env> make integration-test
- (string) Email of the account administrator. To have any effect, needs to specified in conjunction with admin-name and admin-password. Has no effect if changed after a deployment.
- (string) Name of the account administrator. If this, admin-email and admin-password are specified, then the standalone account will be created as part of the deployment, and this person will be its administrator. If not specified, Landscape will prompt for these details when it is first accessed with a web browser. Has no effect if changed after a deployment.
- (string) Password of the account administrator. To have any effect, needs to be specified in conjunction with admin-name and admin-email. Has no effect if changed after a deployment.
- (string) The password to use for the landscape DB user. If you change this post-deployment via juju set, you will have to change the password in the DB manually as the charm will not do it for you yet.
- (string) License file for LDS.
- (boolean) Put this landscape service unit into a maintenance mode. Stop all services and prevent any attempts to start them. Cron jobs will also not run. Upgrade schema attempts will still be allowed to process.
- (string) APT repository (URL only) to use for installing Landscape.
- (string) Many landscape services can have multiple instances started up. By altering this setting, you can increase the launch count. A numeric value will tell all capable landscape services on this juju unit to spawn that number of instances. Leave at the default of "AUTO", to let the charm determine the optimum number of services given the discovered properties of the box (RAM, Disk Space, CPU). You can also supply a syntax of: "<service-name>:<number> <service-name>:<number>" as a value, to control the launch of individual services. Services that cannot "scale" in this way will politely ignore these settings.
- (string) Landscape services listed as space-separated entries. Valid services are: appserver, msgserver, pingserver, combo-loader, async-frontend, apiserver, package-upload, jobhandler, package-search, juju-sync, cron and static.
- appserver msgserver pingserver combo-loader async-frontend apiserver package-upload jobhandler package-search juju-sync cron static
- (boolean) When daemons attempt to start, they will first try to update the schema (instead of just validating that it is correct). This should only typically be enabled as part of a landscape maintenance cycle.