Commit 5c0fe5d5 authored by Walter Heck's avatar Walter Heck

Create proper structure for OpsTheater documentation

parent 7d866db7
### Prerequisites
* Make sure you have installed the following on your host machine:
* virtualbox (http://virtualbox.org)
* vagrant (https://www.vagrantup.com/)
* vagrant plugin oscar (https://github.com/oscar-stack/oscar)
* Download the Puppet enterprise installer you will use at least for the master (by default this is PE 2015.2.2 on CentOS 7):
* PE 2015.2.0:
* https://s3.amazonaws.com/pe-builds/released/2015.2.0/puppet-enterprise-2015.2.0-ubuntu-14.04-amd64.tar.gz
* https://s3.amazonaws.com/pe-builds/released/2015.2.0/puppet-enterprise-2015.2.0-el-7-x86_64.tar.gz
* https://s3.amazonaws.com/pe-builds/released/2015.2.0/puppet-enterprise-2015.2.0-el-6-x86_64.tar.gz
* PE 2015.2.2:
* https://s3.amazonaws.com/pe-builds/released/2015.2.2/puppet-enterprise-2015.2.2-ubuntu-14.04-amd64.tar.gz
* https://s3.amazonaws.com/pe-builds/released/2015.2.2/puppet-enterprise-2015.2.2-el-7-x86_64.tar.gz
* https://s3.amazonaws.com/pe-builds/released/2015.2.2/puppet-enterprise-2015.2.2-el-6-x86_64.tar.gz
* PE 2015.3.0:
* https://s3.amazonaws.com/pe-builds/released/2015.3.0/puppet-enterprise-2015.3.0-el-7-x86_64.tar.gz
### Setting up opscentre in an oscar environment
* First of all install oscar plugin for vagrant with following command :
```
vagrant plugin install oscar
```
Please note that you need to run vagrant command from the location of your Vagrantfile
in this case location of Vagrantfile is : `~/opscenter-oscar/`
* Clone this repository on your host machine and initiate the submodules also:
```
git clone git@github.com:olindata/opscenter-oscar.git
cd opscenter-oscar/
git submodule update --init
```
* Use the pe-build plugin that comes with oscar to place the downloaded puppet enterprise installer in the correct location on your host.
`vagrant pe-build copy /path/to/puppet-enterprise-2015.2.0-el-7-x86_64.tar.gz`
Make sure to update the version of PE you are using in the `opscenter-oscar/config/pe_build.yaml` file. It will determine which file in the pe_builds directory oscar searches for.
* Bring up the puppet master vm and log into it:
```
vagrant up master
vagrant ssh master
sudo su -
```
* You might also want to install r10k or puppet-librarian on your host machine and install the modules the opscenter-control repo uses on your host so you can browse through them.
* Now bring up one or more agents with oscar on your host machine
```
vagrant up gitlab
```
# Installation
1. Requirements gathering phase
1.1 which tools do they want to use of the OpsTheater stack
1.2 hostnames
Recommended…
* master.opstheater.companyname.xxx (puppetmaster / foreman (if foss))
* monitoring.opstheater.companyname.xxx (icinga)
* logging.opstheater.companyname.xxx (kibana / other techs…?)
* code.opstheater.companyname.xxx (gitlab / mattermost)
1.3 resource allocation (either the default scheme or custom if need be)
1.4 HTTPS Yes or No?
If yes, need certificates for above hostnames
1.5 users (name, email address), groups
We need to create a sheet of sorts to collect what types of users and what types of access to be given eg:
Foreman users
Puppet users
Shell users (admin access)
Gitlab / Mattermost users
Icinga users
1.6 SMTP Relay information for our stack being able to send emails
SMTP Server Hostname
SMTP Server Port
Authenticated? If yes...
username:
Password:
Uses TLS?
Uses StartTLS?
1.7 any custom requirements
1.8 any needed migrations from other tools
1.9 Choice of provider(s) (cloud / physical)
2. deploy vms/physical nodes
3. Installation of master server (FOSS or not)
More details…
4. Customization of client-specific opstheater-control repository to include client-specific configuration, SSL certificates, URLs, SMTP provider, etc.
details...
5. Installation of requested OpsTheater-provided servers & services
master.opstheater.companyname.xxx (puppetmaster / foreman (if foss))
monitoring.opstheater.companyname.xxx (icinga)
logging.opstheater.companyname.xxx server (kibana / other techs…?)
code.opstheater.companyname.xxx server (gitlab / mattermost)
others...
6. Any manual configuration of OpsTheater servers not yet automated
Currently gitlab / mattermost integration requires a bit of manual attention post-install including…
Creating opstheater-control repository
Pointing the puppetmaster’s code source to the opstheater-control repository on their gitlab installation
Creating demo repository from git@github.com:olindata/sample-ruby-project.git
Setup mattermost
Enable mattermost team creation
Log into mattermost with root user
Create a team
Make the team a public team
disable team creation
TEST IT :P
Create integration
Copy/paste integration URL into gitlab for build notifications
7. (per-request) Client-specific configuration pre-discussed, such as setting up foreman to be able to deploy specific server types.
8. Creation of requested users in the various systems per-requested by the client.
## to be added to opstheater-control
In order to make deploys easier and upgrades also, we (W+F) propose something along the lines of this:
another hiera level 70.opstheater_custom
rename 60.opstheater to 60.opstheater_defaults
create besides the role and profile module also a module for each client that lives locally in their gitlab instance. We add it to their puppetfile so it gets deployed nicely
from 70.opstheater_custom we can have keys refer to a path in the client specific module
**NOTE: This is a guide used by OlinData BV for handling releases of OpsTheater. As an end user you do not need to use this guide.**
# Release cycle
Problems notwithstanding we release a new version of OpsTheater every month on the first of the month. Our timing is based on and coincides with a number of the software packaged within OpsTheater. Security releases are published when needed. Our changelog for the release will contain changes, new features, and packaged software version information.
# Release timing
Monthly release, the 1st day of every month.
Patch release, for serious bugs or security problems.
# Monthly Release Internal Process
**NOTE: This is a guide used by OlinData BV for handling releases of OpsTheater. As an end user you do not need to use this guide.**
# Release process
# Release cycle
1. On the 23rd of each month, we feature-freeze opstheater-control and freeze versions of included tools
2. create a branch pre-release off of that version?
3. list out current stable versions of the tools included in opstheater
4. We test upgrade from previous stable version
5. We test fresh deploys
6. We incorporate any extra changes only if they are otherwise breaking
7. We create release notes
8. on the 28th of each month, we release the new version and help clients with support contracts upgrade
9. a tarball of the pre-release branch named after whatever version tag it then has
Problems notwithstanding we release a new version of OpsTheater every month on the first of the month. Our timing is based on and coincides with a number of the software packaged within OpsTheater. Security releases are published when needed. Our changelog for the release will contain changes, new features, and packaged software version information.
For a log of 1.4 release process see: https://github.com/olindata/opstheater-control/issues/55
# Release timing
This borrows heavily and is modeled after: http://doc.gitlab.com/ce/release/monthly.html
Monthly release, the 1st day of every month.
Patch release, for serious bugs or security problems.
# Monthly Release Internal Process
1. The process starts the 23rd of every month, in which we evaluate the stability and inclusion of newer versions of our included packages. The release manager decides on a version of all supporting packages and creates a ChangeLog to be included with the release and documented in this repository under releases/x.x.x_changelog.md
......@@ -24,7 +28,3 @@ Patch release, for serious bugs or security problems.
5. When the first of the month rolls around, if there were no problems with the release, a release is created in github from the release branch, and any changes made are PR'd back to the master branch for approval by another core team member. This tag is not to be purged after the PR is merged to master, but to remain in git forever.
6. At this point, we send an update notification email to any subscribers to OpsTheater mailers and begin the process to upgrade all of our OpsTheater installations that are paid subscribers. As part of the signup process with our customers, we decide on a day-of-the-week and time to perform maintenance on their OpsTheater. Following their requested schedule, we perform the necessary upgrade, and inform our customers of this 2 days before, and if there is no objection then also notify them as we begin the upgrade procedure, and after its completion along with a changelog of any platform changes/improvements/etc.
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment