1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
|
Deploying Capomastro
====================
Requirements
------------
* Launchpad:
* Access to the spec code at lp:~canonical-is/canonical-mojo-specs/mojo-pes-capomastro/
* Access to Jenkins bot keys at lp:~ce-infrastructure/bygmester/ce-jenkins-bot
* Access to the PPA at lp:~ce-infrastructure/+archive/ubuntu/capomastro
* OS:
* Trusty (14.04)
Setup
-----
Install the Mojo package from its PPA (and juju-local if doing local test):
sudo apt-add-repository --yes ppa:mojo-maintainers/ppa && sudo apt-get update
sudo apt-get --yes install mojo juju-local
Initialize the local environment for Juju so you can deploy Capomastro:
juju init
juju switch local
juju bootstrap
It is also highly recommended to use the company VPN to run any deployment, see
https://wiki.canonical.com/InformationInfrastructure/IS/HowTo/CompanyOpenVPN
for instructions on how to set it up. You may have problems accessing IS-owned
resources if you do not use the VPN when running the Mojo script.
Mojo configuration
------------------
There are two important vars in the deployment script: MOJO_REPO and MOJO_STAGE.
MOJO_REPO should have the Launchpad address of the repository containing the spec
of Capomastro. It can be a local repository, i.e. a local directory in the file
system, as long as all changes have been committed (not necessarily pushed though).
MOJO_STAGE point to the working spec directory inside the Mojo repository. You
may need to tweak that if you are working on a new spec which does not follow the
IS organization, but most likely that never needs to be changed.
Also, before running the deployment script, you must have both the secret of Capomastro's
PPA and the SSH key pair used by the Jenkins bot to fetch and build images.
The script expects the Capomastro PPA to be configured through a charm option
and it is copied over the rest of the Mojo files automatically. Just put the
option formatted as YAML in /tmp/secrets, like this:
capomastro:
services:
capomastro:
options:
repository: "<private PPA credentials here>"
As for the Jenkins bot configuration, simply create a directory /tmp/keys
and add both SSH key and its .pub inside it. The script will use them for some
post desployment steps, otherwise Jenkins won't be able to fetch and build
images correctly right after the setup of the service.
All this ensures no secrets or credentials are stored anywhere in the spec.
Deploying
---------
You may need to provide a password for sudo at the start of it:
./mojo.sh
Considerations
--------------
1. you should avoid using this script for any serious production deployment. This
was meant for testing and development only, though it could be used just fine
on staging servers if needed. Local deployments with Juju and Mojo are supported
but you may encounter unknown problems, so beware. Ideally you should always
deploy to Canonistack, but that is quite slow, that's why this script exists.
2. if using a non-local provider you will need to associate a floating IP with
the "apache2/0" service unit for web access. Optionally associate a floating
IP with the "jenkins/0" service unit if you require web access to it as well,
but keep in mind that would be insecure as all artifacts by default are visible
in Jenkins.
3. when using this locally, you won't be able to actually build images with
Capomastro right away as the default policy for LXC units is not to allow
nesting. You'll need to stop the Jenkins unit, update its policy to allow that,
restart the unit and then try again. These are the config options you'll need:
lxc.aa_profile = lxc-container-default-with-nesting
lxc.mount.auto = cgroup:mixed
Old references
-------------
Previously, in the shellscripts used to deploy the Capomastro charm manually,
these were the equivalent to the new Mojo spec commands we are using:
init.sh -> collect script
deploy.sh -> the manifest file at the root of the spec
bootstrap.sh -> manually done only when needed now
post-deploy-config.sh -> also part of the manifest file
upgrade-charm.sh -> collect-upgrade script
config/ directory -> services file
|