Evolutionary Improvements to Codenvy Installation

[TylerJewell]

This is a large tracking epic for a number of structural improvements that we will make to the Codenvy installation process to simplify it over time. Each item in the epic list can be taken individually and released in different milestones.

• Validate command line options for bootstrap script. #404
• Change text in bootstrap script: "Checking access to external dependencies..." to "Checking installation repositories...". Remove the unnecessary new line between this statement and the first repo. (was done as part of (#459) fix requesting to Codenvy API throught HTTPS #536)
• Add "invite user by email through factory" use case. Invite user with email address and factory URL #529
• Preload a default set of Factories into CE database, so all installations have them. Preload a set of Factories into a CE installation #530
• Rename /home/codenvy-im/codenvy-im-data to /home/codenvy-im/data. Change path to Installation Manager Server #532
• Rename /home/codenvy-im/codenvy-im-tomcat to /home/codenvy-im/tomcat. Change path to Installation Manager Server #532
• Place the bootstrap script at http://get.codenvy.com. This URL will load the default installation bootstrap script. See http://get.replicated.com for an example. Reorganize install.codenvycorp.com and start.codenvy.com servers #508
• Add new pre-flight check to verify all necessary ports are available. See specification below. Improve pre-flight check to verify all necessary ports are available #480
• Add post-flight check. This will be performed at the end, before we print out "CODENVY INSTALLED"! See specification below. Add post-flight Codenvy on-prem installation check #479
• Add codenvy support command to the CLI, which executes the support script and then informs the user where the TAR support bundle is.
• Investigation of the Dockerization of Codenvy

Codenvy Installation Dictionary

Stage                    | Tool to execute | Option to skip stage            | Issue
-------------------------------------------------------------------------------------
pre-flight check         | boostrap script | --skip-pre-flight-check         | #480
post-flight check        | che-test tool   | --skip-post-flight-check        | #479
post installation action | che-action tool | --skip-post-installation-action | 

Evolution of Codenvy to Dockerization

The objective is to run Codenvy and the Codenvy Manager entirely as a set of Docker containers. The new system could potentially be installed on top of a container orchestrator like OpenShift or Kubernetes. This will be a series of incremental steps that we need to take, each one potentially releaseable for testing. The challenging part of any migration is how to maintain configuration management control. The ability for a customer to define a set of properties and then for those properties to be enforced across a set of containers which may be running at a point in time.

For the purposes of this dialog:
a: We have Codenvy, which has dependencies like postgres, haproxy, gorouter.
b: We have puppet, which is the configuration management system.
c: We have the codenvy manager, aka IM, which is a Tomcat application on Java.
d: We have the bootstrap script, which is bash shell.
e: We have the curl launcher, which is a way to download & launch a bootstrap script.

1: Consolidate all of our databases into a single repository. This will make the installation of Codenvy faster, and potentially shrink the size of an image that contains Codenvy.

2: Package Codenvy, Puppet, and all of its dependencies into a single Docker image. The Codenvy Manager would install and run normally. Instead of installing puppet, it would - instead - launch a container that already has puppet + codenvy installed. It would then trigger some configuration, for which Codenvy would update itself. The database, project files, and product configuration would all be saved to the host through a volume mount. This would be for the single-node configuration only. As part of this exercise, we would change the bootstrap script to a) perform pre-flight checks, b) install and configure Docker, c) install and configure codenvy-manager, which d) then launches the codenvy container. In this scenario, configuration management is embedded entirely within the Codenvy container. Users that make configuration changes would have those configuration changes take affect within the container itself.

3: We would then investigate how additional Swarm nodes would could be launched as containers.

4: We would then investigate how the Codenvy Manager could be packaged as its own Docker container.

5: We would then investigate how we could have all configuration managed externally from the Codenvy container, so that any configuration can be applied to any version of Codenvy, and the Codenvy container accepts it.

6: We would then investigate how we could pull out HAProxy and Postgresql as containers that run independently of the Codenvy container. We would then need to investigate how we can support launching groups of containers collectively on top of Kubernetes and OpenShift.

Ignore: - Future: Contents of Bootstrap Script - Sets Up Host to Accept SSH Commands From Docker

#!/bin/bash
echo "Check if the public key exists in the authorized keys."
if [ -f /keys/id_rsa.pub ]; then
  grep -f /keys/id_rsa.pub /.ssh/authorized_keys
  if [ "$?" -eq "0" ]; then
    # The key exists and is in the authorized keys.
    exit 0
  fi
fi

echo "Generate a new key, if it does not exist"
if [ ! -f /keys/id_rsa.pub ]; then
  echo "Install the ssh-keygen command"
  apt-get update && apt-get install -y keychain && rm -rf /var/lib/apt/lists/*

  echo "Create an ssh key"
  ssh-keygen -f /keys/id_rsa -t rsa -N ''
fi

echo "Write the public key to the authorized keys file"
cat /keys/id_rsa.pub >> /.ssh/authorized_keys

Contents of Docker Container - Invokes SSH Commands Into Host

#!/bin/bash

# Probably have this baked into the container that is run
apt-get update && apt-get install -y ssh && rm -rf rm -rf /var/lib/apt/lists/*

# SSH to the host and then execute the "run_on_host.sh" script on the host
ssh -i /keys/id_rsa -o StrictHostKeyChecking=no root@<host-ip> 'bash -s' < /run_on_host.sh

# run_on_host.sh is a bash file that is included in the container
# the contents of that file will be executed as root on the host

[TylerJewell]

Replaced dockerization epic.