Auto Configuration service allows Cloud users to run pre-installed sets of software, effectively eliminating the need to install and configure it manually. The service is based on Opscode Chef tool and uses Ruby system configuration scripts.
- Cloud Computing Service (C2S)
- Cloud Networking Service (CNS)
- Cloud Block Storage Service (CBS)
- Infrastructure Scheduling Service (CRON)
- Cloud Security Service(CS2)
- Cloud Identity Service (SSH)
- Auto Configuration Service (ACS)
- Terraform As A Service(TAS)
- Telemetry As A Service (TMS)
- Cloud Monitoring Service (CMS)
- CloudWach & SSM (SSM)
- Cloud Formation Service (CFS)
- Log Aggregation Service (LAS)
- Load Balancer Service (LBS)
- Relational Database Service (RDB)
- Docker Service (DOS)
- OpenShift as a Sevice (OSS)
- Kubernetes as a Service (KUB)
- Jenkins as a Service (JaS)
- Gerrit as a Service (GAS)
- Sonar as a Service (SQS)
- Artifactory as a Service (AFS)
- Messaging Service (MES)
- Cloud Support Service (CSS)
Auto Configuration Service (ACS)
This topic contains the following sections:
- Auto Configuration Overview
- Related CLI Commands
- Service Activation and Management
- Manipulating Chef Server
- Collecting Info on Chef Clients
- Reconfiguring Your VM with Chef Roles
Have a Question?
The current page gives the general information on the service and the main workflows. However, while working with the services, our users encounter new questions they need assistance with. The most frequently asked questions on EPAM Cloud Services are gathered on the Cloud Services FAQ page. Visit the page to check whether we have a ready answer for your question.
Auto Configuration Overview
Auto Configuration is an important part of Cloud service provisioning. Currently, EPAM Orchestrator supports convenient auto configuration scenarios for both Windows and Linux-based systems. Each user can select the one which is the most convenient for their purposes and expertise level.
The general scheme of available auto configuration options is given below:
As you can see from the scheme, there are three main auto configuration scenarios available for EPAM Cloud users. Each of them can be specifically convenient and effective, if used under proper conditions.
- Running a script. This option is recommended if you need quick start and single interaction is enough. You can develop your own script, for either Linux or Windows VM, upload it to Orchestrator using or2uf Maestro CLI command, and then specify this script at instance run, so that it will be executed as soon as the instance is created.
- Using Ansible and SSH. Ansible can be used to configure VMs automatically by accessing them via SSH keys. All you have to do is set up Ansible environment and Dynamic Inventory, using Maestro CLI tools. Please note that to use Ansible effectively, it is highly recommended to set up Multiple CLI workspaces (as described further on this page)
- Using Chef In case you plan to implement long-term auto configuration solutions, and need higher level of security, disaster-recovery and availability, it is recommended to use Chef. EPAM Orchestrator provides a number of pre-configured recipes that can be used to configure VMs with a single command call. In addition, you can develop your own recipes, depending on your project needs, and apply them when needed. Besides this, you can switch between different Chef servers by using the Chef service provided by Orchestrator.
Related CLI Commands
The table below provides the list of the commands, related to Chef and Ansible manipulations, enabled in EPAM Cloud:
|Chef||or2-manage-service ... -s chef -a||or2ms ... -s chef -a||Starts the service in the specified project and region|
|or2-validate-chef||or2vchef||Collects info on chef clients indicating any errors occured|
|or2-chef-mode||or2cm||Sets one of the existing chef modes to the project|
|or2-describe-chef||or2dchef||Describes the project Chef Server mode|
|or2-set-instance-properties||or2setp||Used with -c/--chefattribute and -h/--chefrole flag to set the desired chef attribute to be used and the role to be set to the instance|
|Ansible||or2-ansible-init||or2ai||Initializes Ansible environment for the specified project and zone|
|or2-ansible-hosts||or2ah||Is used to manage Ansible hosts||or2-ansible-groups||or2ag||Is used to manage Ansible groups||or2-ansible-group-properties||or2agp||Is used to manage Ansible group properties||or2-ansible-dynamic-inventory||or2adi||Is used to retrieve Ansible dynamic inventory|
Further on this page, you can find the examples of the commands usage for Auto Configuration Service manipulation.
Service Activation and Management
Chef-based Auto Configuration Service is available by default as soon as the project gets activated in Cloud. If you are using the default Chef server, no special setup is necessary, you can start using the Chef-related commands immediately.
If you need to disable auto configuration for VMs with specific OS types, rather than for the whole project, add the --customize parameter to the or2-manage-service (or2ms) command with the --activate flag:
or2ms -a -s chef -p project -r region --customize
When run, the command will prompt you for the ACS disable mode. As a response, specify the OS family for which the auto configuration should be disabled (ALL, WINDOWS, LINUX):
The information on the auto configuration disabling on the project can be found in the or2-describe-chef (or2dchef) command:
To enable auto configuration back, run the same or2ms command with the --customize parameter, and select the NONE mode.
To set up Ansible, run the or2ai command and specify your project and region:
or2ai -p project -r region
The command sets up all required configuration files in the current user directory. These are:
- ansible.cfg - Ansible configuration file
- default.properties - contains default values for the required CLI parameteres
- ansible_hosts.sh - the executable script for getting Ansible dynamic inventory
After Ansible environment is configured, you can proceed with Dynamic Inventory setup and further actions.
Manipulating Chef Server
The following ACS modes are available in EPAM Orchestrator:
|Default||-m default||The default mode for all projects in the EPAM Cloud. In this case, a common Chef server is used for all production environment machines.|
|EPC||-m epc||Use project-specific Chef server, created by EPAM Orchestrator for the specified project.|
|User||-m user||Use project-specific Chef server, created and properly configured by the user. When switching to this mode, the user should provide Chef server's instance ID (or instance IP) and manually upload validation.pem file to the Orchestrator's file storage. The user should also provide the path to validation.pem file during the command invocation.|
Chef modes are managed with the or2-chef-mode (or2cm) command. To set up a non-default Chef server, you should start the Chef Service by running the or2cm command setting the Chef mode to EPC:
or2cm -p project -r region -m epc -y
This command starts a virtual machine to act as your project Chef server. All instances started under your project after the Chef mode switch, will be registered by the project server.
Setting the current Chef server to project will not apply any actions on the virtual machines running in this project. Re-configuration of the software on instances is not allowed.
To apply auto-configuration changes, you need to re-register existing VMs on the new Chef server.
You can share an existing EPC Chef server among several regions, projects and Cloud Platforms. To connect another region or project to an existing EPC Chef server, you will have to add its Service ID to the or2-manage-services command run for the project/region you want to add:
or2cm -p project -r region -m epc -S serviceid
In this way, you can share an existing Chef server between regions within one project or between different projectsthat are used for the same product or cutomer.
To establish a cross-project connection, you should have permissions to run the or2-change-mode (or2cm) command in the project which you will connect to the Chef server. In case you are not assigned to the project hosting the existing chef server, the Project Coordinator should provide you with the server service ID.
To disable auto-configuration for your project, use the or2-manage-service (or2ms) command with the --deactivate option:
or2ms -p project -r region -s chef --deactivate
Note that the command disabling auto-configuration will not terminate the project Chef server, if existing.
This command does not remove any resources created during the service performance.
To revert to the default Chef server, use the or2-chef-mode (or2cm) command to set the Chef mode to default. This command will automatically terminate the project Chef server.
It is impossible to start services in a project/region, if its Chef mode is set to USER.
You can use the or2-describe-chef (or2dchef) command to get the current Chef mode, Chef Server DNS and Chef Server state:
or2dchef -p project -r region
Collecting Info on Chef Clients
The or2-validate-chef (or2vchef) command of the Maestro CLI allows the user to control and monitor the work of the service indicating any errors occurred. The command should be run in Maestro CLI on the target VM and does not need any parameters:
The command output includes the following information:
Please see the Maestro CLI Quick Start Guide for more information about Maestro CLI installation.
Reconfiguring Your VM with Chef Roles
In order to set a chef role or several roles for an instance, you can use the or2setp command with alias that allow to simplify the role assignment. The -c/--chefattribute parameter is used to specify the desired chef attribute to be used, and -h/--chefrole - the role to be set to the instance:
or2setp -i instance_id -h role1 -h role2 -c value1 -c "recipename1.attribute1=value2" -p project -r region
The table below describes the most frequently used chef roles (except for those that have already been engaged in platform services provisioning):
|lamp||Installs Apache, MySQL, PHP||apache.default_site_enabled=true||Enables default apache host|
|mysql-master-master||Installs MySQL with mater master replication||project=project1||MySQL cluster name|
|mysql.tunable.server_id=1||Unique server ID|
|allow_remote_root=true||Allow root to perform remote connection|
|mysql.server_repl_password=qwerty||Root user password (generated randomly by default)|
|mysql.server_root_password=123qwe||Replication user password (generated randomly by default)|
|tomcat6||Installs Tomcat 6||tomcat.port = 8080||Tomcat app port|
|tomcat.ajp_port = 8009||Tomcat ajp port|
|tomcat.java_options = "-Xmx128M-Djava.awt.headless=true"||Java options for Tomcat|
|tomcat7||Installs Tomcat 7||tomcat.port (optional)||Tomcat app port(default: 8080)|
|tomcat.ajp_port (optional)||Tomcat ajp port(default: 8009)|
|tomcat.java_options (optional)||Java options for Tomcat (default: "-Xmx128M-Djava.awt.headless=true"|
|maestro-cli||Installs Maestro CLI||-||-|
The service usage influences the project cost in case the Chef mode is switched to EPC. In this case, a special VM for project Chef Server is created. This VM has the following parameters:
- Shape: MEDIUM
- Image: Ubuntu16.04_64-bit
It is billed just as any other VM of such type. Therefore, the approximate monthly cost of such server in case of 100% and 24/7 load is about $30.64 in EPAM-BY2 region (as to July 2020). The price can vary depending on the region. To get more detailed estimations, please, use our Cost Estimator tool.
When the Chef mode is switched from EPC to any other one, the VM launched for EPC mode is terminated.
Using Ansible does not apply additional charges on your project.
Multiple CLI Workspaces
When working with Ansible auto configuration, it is important to have a set of pre-configured Maestro CLI parameters that would be automatically fetched and processed.
These parameters are set in %Maestro_CLI%lib/default.properties file according to property_name=property_value syntax. For example, default project and region specification would look like:
However, there is a typical need in using several environments in different locations and projects, or in having different sets of default parameters. This is possible by setting up different workspaces with different defaults collections.
To set up a multiple workspaces, perform the following steps:
- 1. Add the %Maestro_CLI%bin path to the PATH environment variable
- 2. On your workstation, create a new folder for a new workspace. We would recommend to name it after project and region in which you are going to use this workspace.
- 3. Create a cli.properties file in the new folder and specify the properties for the new workspace in it. (if you initiate Ansible configuration, in this folder, this file will be automaticlly created)
After that, when working with Maestro CLI, just switch to the necessary workspace and run a command. The default properties will be automatically taken from the currently active folder. If the current folder includes no properties file, those specified in %Maestro_CLI%lib/cli.properties will be used.
More information on Chef Service can be found in the EPAM Cloud Services Guide. For detailed description of the Maestro CLI commands used to manage the Auto Configuration Service, refer to the Maestro CLI User Guide. More information about Ansible usage can be found in the Ansible User Guide document, attached to this page.
Below is a list of documents related to this section. You can find the full list of our documents in the Documentation Storage.
Please select a required document:
This guide provides instructions on how Ansible can be used as an auto-configuration tool within EPAM Private Cloud