Subordinate charm used to populate a directory with content grabbed from an external source. Can be used with the apache2 charm to populate the docroot
- misc ›
Juju charm for deploying content to Apache
How to deploy the charm
Use this charm as a subordinate to a charm like apache2. It will download the content and install it on the server.
This charm can be joined to a remote-content relation if the superordinate needs to take action after content is updated. If no action is needed it can be joined to the generic juju-info relation. If remote-content is used then the superordinate can set the dest_dir
Currently swift, bzr+ssh, file, lp, http, https and ftp are supported. http, https and ftp access can either be anonymous or via a username and password. bzr+ssh requires a private key to be shipped with the charm, this should be a private key which is used for nothing else. swift requires the full gamut of authentication information.
dest_dir is the location to expand the archive into. In the case of apache this would most likely be the document root specified in the vhost
keep_dir_count is the number of backups of the deployed content to keep. Before each deploy the current content is archived before the new content is pulled in.
By default any change to the charm state i.e. upgrade-charm or config-changed will trigger the content update process to run. This behaviour can be changed by setting update_on_change to false in which case deploy_trigger is used to trigger a deploy of new content and should be incremented to trigger a deploy. Note that when update_on_change is false setting any other parameter will not trigger a deployment.
Examples (not exhaustive:) http, https and ftp:
archive_location=http://192.168.0.1/content.tar archive_location=https://user:email@example.com:4343/content.tar archive_location=ftp://192.168.0.1/content.tar archive_location=ftp://user:firstname.lastname@example.org:912/content.tar
username=$OS_USERNAME secret=$OS_PASSWORD archive_location=content.tar auth_url=$OS_AUTH_URL tenant_name=$OS_TENANT_NAME container_name=my_container
Copy private key to ssh-key/content_fetcher_rsa within the charm
archive_location=bzr+ssh://%s@%s/%s ssh_host_key=<host key of server with content>
High level example:
Below is how the charms relate to one another
juju deploy apache2 juju deploy content-fetcher archive_location=http://192.168.0.1/content.tar juju add-relation apache2:juju-info content-fetcher:general-info
How to upgrade website content:
juju set content-fetcher deploy_trigger=<current_value + 1>
Testing the Charm
These are functional tests which deploy charms and then test retrieving content from different sources
1) Get a local copy of the charm as it contains the test server
git clone lp:content-fetcher-charm
2) Bootstrap and run tests
export JUJU_REPOSITORY=<local charm dir> juju bootstrap make runtests
- Add git support
- Update tests for juju 2
- (string) URL for archive or path to file within the container for swift. Used by all types
- (string) URL for authenticating against Keystone. Used by swift
- (string) Swift container to put objects in. Used by swift
- (int) Increment to trigger a content update. Used by all types
- (string) Destination to hold contents. Used by all types
- (int) Number of backups of old content to keep. Used by all types
- (string) Openstack domain containing the project. Used by Swift with Keystone API v3.
- (string) Secret to use, could be key or password. Used by swift
- (string) The host key of the server with remote content. Used by bzr+ssh
- (string) Swift entity that owns resources. Used by swift. In keystone API v3, this value will be used for the project name.
- (boolean) When true any charm config change or upgrade charm triggers a fresh fetch and deploy of content. When false new content is only updated by incrementing deploy_trigger
- (string) Openstack domain containing the user. Used by Swift with Keystone API v3.
- (string) Username to use. Used by swift