Migrate from an earlier version of BCD
Overview
This page explains how to upgrade your version of BCD.
Each of the versions follows the MAJOR.MINOR.PATCH format.
We have split this documentation in order to describe the differences between upgrades.
We will focus on :
-
scenarios : indeed you may want to keep your existing scenarios. It will allow you to recreate the same kind of stack or manipulate an existing one (deploy, undeploy, destroy).
-
Terraform metadata : "Terraform must store state about your managed infrastructure and configuration. This state is used by Terraform to map real world resources to your configuration, keep track of metadata, and to improve performance for large infrastructures." https://www.terraform.io/docs/state/.
So if you want to be able to manage an existing stack (i.e. a stack already deployed from a previous version of BCD), you will need to copy and paste this state.
-
bcd controller
-
Vagrant : this part applies only if you use Vagrant virtual machines.
-
Living Application repositories : this part applies only for migrations from a 2.0.x
How it works
From a 3.5 towards 3.6.2
-
Some scenario variables have been renamed to a more coherent name (see BCD Scenario reference)
-
rename
bonita_tenant_login
tobonita_technical_username
-
rename
bonita_tenant_password
tobonita_technical_password
-
From a 3.4.5 towards 3.5.0
Scenarios
Lots of previous parameter are now obsolete because of stack
command removal. Please refer to the scenarios reference page to update your scenario files.
BCD controller
As is described in the "Installation guide" from the Getting started you will need to load the last version of bcd-controller_<version>.tar.zip
Docker image.
You also need to retrieve the latest image from the secured Docker registry.
$ docker login quay.io
Username: bonitasoft+john_doe_at_acme_com
Password:
$ docker pull quay.io/bonitasoft/bcd-controller:{bcdVersion}
The username and the password should have been provided by your sales representative.
If you chose to persist your docker console history (see bcd controller) and want to keep it, then you should copy your .bcd_bash_history
file from your old folder to your new bonita-continuous-delivery_3.6.2/
folder
$ cp bonita-continuous-delivery_3.4.5/.bcd_bash_history bonita-continuous-delivery_3.6.2/.bcd_bash_history
From a 2.1.x towards 3.4.5
Scenarios
First, you will need to copy the files:
$ cp bonita-continuous-delivery_2.1.0/scenarios/*.yml bonita-continuous-delivery_3.6.2/scenarios/
Then you will have to check Breaking changes
section in the release notes. Indeed you will have to add the new variables bcd_registry_user
and bcd_registry_password
in order to retrieve BCD dependencies from Bonita secured Docker registry.
Besides, the bonita_edition
variable has been deprecated in BCD 3.0.0 (read BCD 3.0.0 Release Notes for further details).
Therefore, you may remove this variable from your scenario files as it will be ignored.
Terraform
Copy the directory corresponding to your stack:
$ cp -r bonita-continuous-delivery_2.1.0/terraform/your_stack_name bonita-continuous-delivery_3.6.2/terraform/
BCD controller
As is described in the "Installation guide" from the Getting started you will need to load the last version of bcd-controller_3.6.2.tar.zip
Docker image.
You can also directly use the secured Docker registry to retrieve the latest image.
$ docker login quay.io
Username: bonitasoft+john_doe_at_acme_com
Password:
$ docker pull quay.io/bonitasoft/bcd-controller:3.6.2
The username and the password should have been provided by your sales representative.
If you chose to persist your docker console history (see bcd controller) and want to keep it, then you should copy your .bcd_bash_history
file from your old folder to your new bonita-continuous-delivery_3.6.2/
folder
$ cp bonita-continuous-delivery_2.1.0/.bcd_bash_history bonita-continuous-delivery_3.6.2/.bcd_bash_history
BCD Controller image starting from version 3.4 is now using a Debian based distribution (not an Alpine Linux anymore)
|
If you have a customized controller in your setup (i.e. to manage user id mapping), you’ll have to rebuild it and perform changes required from Alpine to Debian.
Vagrant
As the controller access to them over the network it’s not necessary to move them on the filesystem.
But if you plan to clean up the old directory you can move the vagrant data located inside 1-machine
or 2-machines
directories by copying the .vagrant
subdirectories.
$ cp -r bonita-continuous-delivery_2.1.0/vagrant/1-machine/.vagrant bonita-continuous-delivery_3.6.2/vagrant/1-machine/
$ cp -r bonita-continuous-delivery_2.1.0/vagrant/2-machines/.vagrant bonita-continuous-delivery_3.6.2/vagrant/2-machines/