This project provides the required sample playbooks and roles to create the new instance of an application1 to provision Db2 schema.
It is a good practice to review the playbook sample contents before executing them. It will help you understand the requirements in terms of space, location, names, authority, and the artifacts that will be created and cleaned up. Although samples are written to operate without the need for the user’s configuration, flexibility is written into the samples because it is not easy to determine if a sample has access to the host’s resources. Review the playbook notes sections for additional details and configuration.
- db2-schema-provision.yml - Handles creating an instance of an application with/without data and retrieving the status of a newly created application instance.
- db2-schema-deprovision.yml - Handles deleting the instance of an application.
- db2_login - Holds tasks to authenticate the user of an application.
- db2_get_app_id - Holds tasks for retrieving the ID of an application.
- db2_get_status_instance - Holds tasks for retrieving the status of an application instance.
- db2_get_subsystem_id - Holds tasks for retrieving the subsystem ID.
- db2_get_team_id - Holds tasks for retrieving the team ID and environment ID.
- db2_post_create_instance - Holds tasks to create a new instance of an application.
- db2_delete_app_instance - Holds tasks to delete an application instance.
These sample playbooks are designed to exploit the Db2 DevOps Experience (DOE) APIs. An environment where Db2 DevOps Experience is installed and operating is required.
In addition, the Db2 schema provisioning sample playbook can be applied after your administrator defines the Db2 subsystem, team, environment and the application, or the set of Db2 objects that can be provisioned as an unit under DOE. These information will be the input parameters for the playbook.
If you are unfamiliar with playbooks, you can review our detailed configuration guide.
Update the playbook-specific variables in vars/db2_schema.yml, based on the behavior that you want.
zos_target_address- Hostname of the system on which Db2 for z/OS DevOps Experience is running. Server name used to access the DOE rest apis.valid_port_number- Port number of Db2 DevOps Experience Server.valid_username- Username used to access the DOE REST API.valid_password- Password used to access the DOE REST API.valid_app_name- The name for the application that the instance is provisioned from. Db2 DevOps Experience validates this name to ensure that it exists.valid_team_name- The name for the team which the instance is provisioned under. Db2 DevOps Experience validates this name to ensure that it exists.valid_inst_name- The name for the newly provisioned instance. The name cannot contain the symbols for less-than (<) , greater-than (>) , or ampersand (&). Db2 DevOps Experience validates this name to ensure that it is unique across all of the existing instances.with_data- Boolean that gives option to user to provision the app instance with or without data.
- To run the DB2 schema provisioning playbook, type the following command from the root of this repository:
ansible-playbook db2-schema-provision.yml
- To run the de-provisioning DB2 schema, type the following command from the root of this repository:
ansible-playbook db2-schema-deprovision.yml
1 An application is a set of objects, such as tablespaces, tables, and indexes that are grouped to be managed and provisioned as a single unit for the use of an application program or a set of application programs. Application objects are logical, which means that they are only references to the objects. When users provision instances of an application, the referenced objects are copied to create the instances.
© Copyright IBM Corporation 2021
Licensed under Apache License, Version 2.0
Please refer to the support section for more details.