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.
EPC Services
- 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)
- Amazon Workspaces As A Service
- 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:
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 for Windows and Linux based VMs is given below:
/acs_option.png)
There are three main auto configuration scenarios available for EPAM Cloud users: using Chef, using Ansible and SSH, and running user scripts. Each of them can be specifically convenient and effective, if used under proper conditions. All virtual machines run with scripts created by the EPAM Cloud team (Windows init and Linux init) which, if necessary, install the Chef Infra Client or run user scripts.
- Running a user 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 by push model from admin workstation. EPAM Orchestrator allows to 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. Such Platform Services provided by EPAM Cloud as OpenShift and Kubernetes are based on Ansible and SSH configuration model.
- 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, which works by pull model. EPAM Orchestrator provides several 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. You can also switch between different Chef servers by using the Chef service provided by Orchestrator. Such Platform Services provided by EPAM Cloud as Autoconfiguration, Cloud Monitoring, Log Aggregation, Load Balancer, Gerrit, Docker, Jenkins, Relational Database, Artifactory and Messenger are based on Chef configuration.
Related CLI Commands
The table below provides the list of the commands, related to Chef and Ansible manipulations, enabled in EPAM Cloud:
Engine | Command | Short Command | Description |
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 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
To enable auto configuration back, run the same or2ms command with the --customize parameter, and select the NONE mode.
Ansible activation and management
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
There are three Chef auto configuration modes that determine which servers will be used by new Chef Infra clients:
- servers served by EPAM Cloud team,
- servers created specifically for the project by EPAM Cloud team,
- servers created specifically for the project by the project team itself.
Mode | Flag | Description |
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
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
You can find the details about available auto configuration roles on our KB page.
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:
project=DEMOPRO
region=EPAM-BY2
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.
Configuring with scripts
When running the VM, it is possible to specify one or several scripts which will be executed via cloud init after launching the VM, e.g. executing Bash for Linux, or a Batch/PowerShell file for Windows.
If a user wants to create a custom infrastructure for the project needs, and uses the same approach for reaching the desired state, the simplest way that still requires customization, is to execute scripts, while running a VM manually or using Maestro Stacks for running VMs, as well as launching stacks with pre-configured scripts.
Using scripts
In EPAM Cloud there is one single EPAM related script that performs all required functions and initiates downloading of custom scripts from EPAM Orchestrator for all cloud providers. This approach allowed to avoid all limitations and allows users to specify any number of supported scripts. If any of custom script has an error, it will not influence the whole VM configuration.
It is possible to specify custom parameterized scripts during virtual machine initialization using or2-run-instance(or2run) Maestro CLI command.
Specifics of the current implementation includes:
- for Linux-based systems – running Shell scripts will be executed at a Bash interpreter,
- for Windows-based systems – PowerShell scripts (with .ps1 extension) will be launched via PowerShell interpreter and Batch scripts (with .cmd extension) will be executed via cmd. Both of them will be launched with the highest privileges.
All scripts support passing the parameters, the values of which can be set during the instance start.
To run an instance with the custom script, invoke or2run (or2-run-instance) command and specify image, project, region, shape and script name.
or2run -i instance_id -p project -r region -s shape -t script_name
Response example:
/script_response.png)
References
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.
Pricing
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: Ubuntu18.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.
Documentation
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:
Ansible User GuideThis guide provides instructions on how Ansible can be used as an auto-configuration tool within EPAM Private Cloud |