To have a pain-free installation a docker environment is provided. This uses a docker-compose file to provide the orchestration for the containers to setup.
Going a step further on easing up the deployment process environment variables are used. These are split in deployment-specific and foundation settings. Any tailoring to the Store instantiation is done to the deployment-specific settings.
The downside of all this auto-magically environment instantiation is that the actual docker files get a bit harder to read and a setup orchestrator script needs to be put in place to fill in the proper data in the docker files according to the variables defined for the environment. The outcome of all of this tweaking is that the docker files are created as templates (docker-compose.yml.tmpl, docker-compose.qa.yml.tmpl, Dockerfile.store.tmpl, Dockerfile.datastore.tmpl, Dockerfile.qa.tmpl) and the orchestrator script (run.sh) produces the proper docker files, builds them up and runs the containers so the Store is up and running as intended.
In order to allow for testing without disrupting the Store operation, ensure new features won't introduce regressions, a new deployment is properly set up or even prevent any downtime during misbehaviour analysis environments are introduced. The purpose behind such environments is to separate concerns and provide for the flexibility mentioned.
Any tailoring to the Store deployment is done through the variables below. These variables are defines in a file and provided to the setup orchestrator script as a parameter (further details available on the help message for the script).
| Variable | Purpose | Format |
|---|---|---|
API_PORT |
TCP port where the Store REST API is running. | Number. User or Dynamic Port number as defined by RFC 6335 |
VNSFO_PROTOCOL |
Protocol used to communicate with the vNSF Orchestrator | String. http or https |
VNSFO_HOST |
vNSF Orchestrator IP address | String. IP or DNS name where the vNSFO is running |
VNSFO_PORT |
vNSF Orchestrator IP port | Number. Port number where the vNSFO REST API is listening for requests |
VNSFO_API |
vNSF Orchestrator API basepath | String. Basepath to the vNSFO onboarding REST API |
For your convenience some environments are already defined. These are:
| Environment | File | Purpose |
|---|---|---|
| Production | .env.production |
Put into operation for the intended use |
| Staging | .env.staging |
Replicates (as closely as possible) the production environment so a "test-drive" can be done and potential issues uncovered. Also be used for development purposes to have a better understanding of what is happening |
| QA | .env.qa |
Quality Assurance settings used to verify no regressions were introduced by new features being deployed. This provides a mock for the vNSF Orchestrator API. |
The tools below are used to provide all the environments auto-magically instantiation.
-
run.shis the Store environment instantiation orchestrator. It builds the docker files according to the environment to instantiate based on the defined templates -
setup-store.shensures the Store requirements are installed on the container so the code can run and performa as expected -
setup-datastore.shensures the Store data store is up and running according to the settings defined in the environment files -
setup-qa.shtakes care of setting up the requirements for the quality assurance environment so the validation runs against the Store code -
mongodb-init.jsinitializes the data store for the environment being used
docker-compose.yml.tmpldefines the services to run for the Store containerdocker-compose.qa.yml.tmpldefines the services to run for the QA containerDockerfile.store.tmplpackages installation to setup the Store containerDockerfile.datastore.tmplpackages installation to setup the data store containerDockerfile.qa.tmplpackages installation to setup the QA container
requirements-store.txtdefines the libraries required for the Store coderequirements-qa.txtdefines the libraries required for the BDD testing environment