Create ardo_app BOSH release - pivotal-cf/TAS-LTS GitHub Wiki

Create Release BOSH ardo_app

Instructions for run
- To create the release directory, navigate into the workspace where you want t* he release to be, and run the command
```
bosh init-release --dir bosh-tutorial-deployment --git
```
  --git option is additional, it's for initializing a git repository.
  You can download the ardo_app from here. Download the zip file and unzip inside the src directory and rename to ardo_app.
- Step 1: Create Job Skeletons For each job, create a job skeleton: bosh generate-job <job_name> In our example <job_name> is a web_ui use command bosh generate-job web_ui.
  - Create control scripts Every job needs a way to start and stop. You provide that by writing a control script and updating the monit file. The control script: Includes a start command and a stop command. Is an ERB template stored in the templates directory for the relevant job.
    - The control script for the web_ui job looks like this(vim jobs/web_ui/templates/ctl.erb):
      #!/bin/bash RUN_DIR=/var/vcap/sys/run/web_ui LOG_DIR=/var/vcap/sys/log/web_ui PIDFILE=${RUN_DIR}/pid case $1 in start) mkdir -p $RUN_DIR $LOG_DIR chown -R vcap:vcap $RUN_DIR $LOG_DIR echo $$ > $PIDFILE cd /var/vcap/packages/ardo_app export PATH=/var/vcap/packages/ruby_1.9.3/bin:$PATH exec /var/vcap/packages/ruby_1.9.3/bin/bundle exec \ rackup -p <%= p('port') %> \ >> $LOG_DIR/web_ui.stdout.log \ 2>> $LOG_DIR/web_ui.stderr.log ;; stop) kill -9 `cat $PIDFILE` rm -f $PIDFILE ;; *) echo "Usage: ctl {start|stop}" ;; esac
    - The monit file for the web_ui job looks like this(vim jobs/web_ui/monit):
      --- name: web_ui templates: ctl.erb: bin/ctl packages: - ardo_app - ruby_1.9.3 properties: port: description: Port that web_ui app listens on default: 80
    - The templates block of the updated spec files for the example jobs look like this:(vim /jobs/web_ui/spec):
      --- name: web_ui templates: ctl.erb: bin/ctl packages: - ardo_app - ruby_1.9.3 properties: port: description: Port that web_ui app listens on default: 80
- Step 2: Create Package Skeletons
  - Packages give BOSH the information needed to prepare the binaries and dependencies for your jobs. In our example, we run this command three times. Starting from the bottom of the dependency graph, we run it for libyaml_0.1.4, ruby_1.9.3, and ardo_app. Create package skeletons starting from the bottom of your dependency graph. bosh generate-package <dependency_name> For our example run
```
bosh generate-package libyaml_0.1.4
bosh generate-package ruby_1.9.3
bosh generate-package ardo_app
```
  - View the package skeletons with tree:
```
packages
  ├── ardo_app
  │   ├── packaging
  │   ├── pre_packaging
  │   └── spec
  ├── libyaml_0.1.4
  │   ├── packaging
  │   ├── pre_packaging
  │   └── spec
  └── ruby_1.9.3
  ├── packaging
  ├── pre_packaging
  └── spec
```
    Notes
    Use of the pre_packaging file is not recommended and is not discussed in this tutorial.
  - Without using pre_packaging for our ardo_app we need to pack gems manually for further usage:
```
cd src/ardo_app
bundle package
```
  - Update the spec for each package. Refer to the example specs below for guidance.
    - Example libyaml package spec(vim packages/libyaml_0.1.4/spec)
      --- name: libyaml_0.1.4 dependencies: [] files: - libyaml_0.1.4/yaml-0.1.4.tar.gz # From http://pyyaml.org/download/libyaml/yaml-0.1.4.tar.gz
    - Example Ruby package spec(vim packages/ruby_1.9.3/spec)
      --- name: ruby_1.9.3 dependencies: - libyaml_0.1.4 files: - ruby_1.9.3/ruby-1.9.3-p484.tar.gz # http://cache.ruby-lang.org/pub/ruby/1.9/ruby-1.9.3-p484.tar.gz - ruby_1.9.3/rubygems-1.8.24.tgz # http://production.cf.rubygems.org/rubygems/rubygems-1.8.24.tgz - ruby_1.9.3/bundler-1.2.1.gem
    - Example ardo_app package spec(vim packages/ardo_app/spec)
      --- name: ardo_app dependencies: - ruby_1.9.3 files: - ardo_app/**/*
  - Update your packaging scripts. Refer to the example specs below for guidance.
    - Example libyaml packaging script(vim packages/libyaml_0.1.4/packaging)
      set -e -x tar xzf libyaml_0.1.4/yaml-0.1.4.tar.gz pushd yaml-0.1.4 ./configure --prefix=${BOSH_INSTALL_TARGET} make make install popd
    - Example Ruby packaging script(vim packages/ruby_1.9.3/packaging)
      set -e -x tar xzf ruby_1.9.3/ruby-1.9.3-p484.tar.gz pushd ruby-1.9.3-p484 ./configure \ --prefix=${BOSH_INSTALL_TARGET} \ --disable-install-doc \ --with-opt-dir=/var/vcap/packages/libyaml_0.1.4 make make install popd tar zxvf ruby_1.9.3/rubygems-1.8.24.tgz pushd rubygems-1.8.24 ${BOSH_INSTALL_TARGET}/bin/ruby setup.rb popd ${BOSH_INSTALL_TARGET}/bin/gem install ruby_1.9.3/bundler-1.2.1.gem --no-ri --no-rdoc
    - Example ardo_app packaging script(vim packages/ardo_app/packaging)
      set -e -x cp -a ardo_app/* ${BOSH_INSTALL_TARGET} cd ${BOSH_INSTALL_TARGET} /var/vcap/packages/ruby_1.9.3/bin/bundle install \ --local \ --deployment \ --without development test
- Step 3: Add Blobs
  - When creating a release, you will likely use a source code repository. But releases often use tar files or other binaries, also known as blobs.
  - Download all the binary from the official location and make sure the file hash matches.
  - Here is a all files which you need to download
  - Inform BOSH where blobs are
    - Those files are blobs, and now you need the paths to the downloaded blobs on your local system.
      - Go through all your packages and make a list of local paths to the blobs you downloaded. Now you are ready to inform BOSH about these blobs.
      - If you downloaded the blob, its local path might be ~/Downloads. And For each blob, run:
        bosh add-blob ~/Downloads/yaml-0.1.4.tar.gz libyaml_0.1.4/yaml-0.1.4.tar.gz bosh add-blob ~/Downloads/ruby-1.9.3-p484.tar.gz ruby_1.9.3/ruby-1.9.3-p484.tar.gz bosh add-blob ~/Downloads/rubygems-1.8.24.tgz ruby_1.9.3/rubygems-1.8.24.tgz bosh add-blob ~/Downloads/bundler-1.2.1.gem ruby_1.9.3/bundler-1.2.1.gem
  - In the config directory, you record the information BOSH needs about the blobstore:
    - The final.yml file names the blobstore and declares its type, which is either local or one of several other types that specify blobstore providers.
    - The private.yml file specifies the blobstore path, along with a secret.
    - The config directory also contains two files whose content is automatically generated: the blobs.yml file and the dev.yml file.
    - Example final.yml(vim config/final.yml):
      --- name: ardo_app blobstore: provider: local options: blobstore_path: /tmp/ardo-blobs
    - Example private.yml(vim config/private.yml):
      --- blobstore_secret: 'does-not-matter' blobstore: local: blobstore_path: /tmp/ardo-blobs
- Step 4: Create a Dev Release
  - For the dev release, use the --force option with the bosh create-release command. This forces BOSH to use the local copies of our blobs.
  - Without the --force option, BOSH requires blobs to be uploaded before you run bosh create-release. For a final release, we upload blobs, but not for a dev release.
  - Create the dev release:
```
bosh create-release --force
```
  - If BOSH is already pointing to a release, edit the BOSH deployment manifest. Otherwise, create a manifest.
  - Simple manifest for ardo_app can be found here. Download manifest file and move in the project root directory
  - View the release with tree:
```
$ tree .
.
├── blobs
│   ├── libyaml_0.1.4
│   │   └── yaml-0.1.4.tar.gz
│   └── ruby_1.9.3
│       ├── bundler-1.2.1.gem
│       ├── ruby-1.9.3-p484.tar.gz
│       └── rubygems-1.8.24.tgz
├── config
│   ├── blobs.yml
│   └── final.yml
├── jobs
│   ├── web_ui
│      ├── monit
│      ├── spec
│      └── templates
│          └── ctl.erb
├── manifest.yml
├── packages
│   ├── ardo_app
│   │   ├── packaging
│   │   └── spec
│   ├── libyaml_0.1.4
│   │   ├── packaging
│   │   └── spec
│   └── ruby_1.9.3
│       ├── packaging
│       └── spec
└── src
└── ardo_app
├── Gemfile
├── Gemfile.lock
├── app.rb
├── config.ru
└── vendor
└── cache
├── rack-1.5.1.gem
├── rack-protection-1.3.2.gem
├── sinatra-1.3.4.gem
└── tilt-1.3.3.gem
```
- Step 5: Deploying BOSH with create-env
  - An environment consists of the Director and deployments that it orchestrates. First we need to deploy the Director which then would be able to manage other deployments.
  - Choose your next step where to install the Director:
    - On Local machine
    - On AWS
    - On Azure
    - On Google
    - On OpenStack
    - On SoftLayer
    - On vCloud
    - On vSphere
    - On Smith
  - In our example we look to deploy with smith.
  - You need to generate smith env. Go here and generate env.
  - As you alrady have a smith envariment get envariment credentials
```
export TOOLSMITHS_API_TOKEN=0c60a5d3-e1ee-496d-81d9-3f17470444f8; 
smith bosh -e $TOOLSMITHS_ENVIROMENT_NAME
```
  - Past all exports in your terminal
  - Know we need to update our manifest.yml file.
    - Replace stemcells version,
      - Run command bosh -d bosh-tutorial-deployment stemcells get correct version from output and update stemcells->version line
    - Replace with the name of azs defined in cloud-config (to view existing azs, do bosh int <(bosh cloud-config) --path=/azs)
      - After change will look like azs: [us-central1-f](choose one off azs names)
    - Replace with the name of vm_types defined in cloud-config (to view available vm_types, do bosh int <(bosh cloud-config) --path=/vm_types)
      - After change will look like vm_type: small (choose vm type, which in our manifest.yml, which is by default small, here don't needed to change)
    - Replace with the name of networks defined in cloud-config (to view available networks, do bosh int <(bosh cloud-config) --path=/networks)
      - After change will look like networks: - name: YOURENVNAME-pas-subnet
  - Know we can already upload the release.
```
bosh upload-release
```
  - Assuming you are in the release directory, no path is needed with the above command.
    - Deploy
```
bosh -d bosh-tutorial-deployment deploy ./manifest.yml
```
  Once deployment finishes successfully, most likely you will not be able to access the ruby app you just deployed through the browser. It is because there is no firewall rule attached to the vms. You can attach a firewall rule to the vms, or just bosh ssh into the vms and run curl localhost:<port>
  - For testing our application you need ssh one of the jobs vm
    - Run command for getting bosh -d bosh-tutorial-deployment vms vms info, get the web_ui/<vm_id> from output
      bosh -d bosh-tutorial-deployment ssh web_ui/vm-id
    - Do culr requests for checking
      culr localhost:8080 culr localhost:8080/sigterm/SIGKILL
    - With sudo su and monit summary commands you can see ardo_app process is killed(make it fast because BOSH will again start the process automatically).
Useful references

Create ardo_app BOSH release - pivotal-cf/TAS-LTS GitHub Wiki

⚠️ **GitHub.com Fallback** ⚠️

⚠️ GitHub.com Fallback ⚠️