← Back to branch summary

~ubuntuone-hackers/capomastro/deploy

« back to all changes in this revision

Viewing changes to README.md

  • Committer: Caio Begotti
  • Date: 2015-01-12 17:41:19 UTC
  • mfrom: (41.1.7 capomastro-deploy)
  • Revision ID: caio.begotti@canonical.com-20150112174119-uk36bpwxbt29cw67
merging it manually as we dont have tarmac support for this branch

Show diffs side-by-side

added added

removed removed

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