There are three groups of variables required to build BlockScout. The first is required to create infrastructure, the second to build BlockScout instances and the third is required both for infra and BS itself.
For your convenience we have divided variable templates into three files accordingly -
all.yml.example . Also we have divided those files to place them in the
group_vars and in
host_vars folders, so you will not have to repeat some of the variables for each host/group.
To deploy BlockScout, you will setup the following set of files for each instance:
/| - group_vars| | - group.yml (combination of [blockscout+infrastructure+all].yml.example)| | - all.yml (optional, one for all instances)| - host_vars| | - host.yml (combination of [blockscout+infrastructure+all].yml.example)| - hosts (one for all instances)
The subsections below describe the variables you may want to adjust.
terraform_location is an address of the Terraform binary on the builder;
dynamodb_table represents the name of table that will be used for Terraform state lock management;
ec2_ssh_key_content variable is not empty, Terraform will try to create EC2 SSH key with the
ec2_ssh_key_name name. Otherwise, the existing key with
ec2_ssh_key_name name will be used;
instance_type defines a size of the Blockscout instance that will be launched during the deployment process;
db_subnet_cidr represents the network configuration for the deployment. Usually you want to leave it as is. However, if you want to modify it, please, expect that
db_subnet_cidr represents not a single network, but a group of networks started with defined CIDR block increased by 8 bits.
An internal DNS zone with
dns_zone_name name will be created to take care of BlockScout internal communications;
root_block_size is the amount of storage on your EC2 instance. This value can be adjusted by how frequently logs are rotated. Logs are located in
/opt/app/logs of your EC2 instance;
Each of the
db_* variables configures the database for each chain. Each chain will have the separate RDS instance;
instance_type represent the size of the EC2 instance to be deployed in production;
use_placement_group determines whether or not to launch BlockScout in a placement group.
blockscout_repo - a direct link to the BlockScout repo;
branch - maps branch at
blockscout_repo to each chain;
merge_commit variable if you want to merge any of the specified
chains with the commit in the other branch. Usually used to update production branches with the releases from master branch;
skip_fetch - if this variable is set to
true , BlockScout repo will not be cloned and the process will start from building the dependencies. Use this variable to prevent playbooks from overriding manual changes in cloned repo;
ps_* variables represents a connection details to the test Postgres database. This is not installed automatically, so make sure
ps_* credentials are valid before starting the deployment;
ansible_host - is an address where BlockScout will be built. If this variable is set to localhost, also set
local for better performance.
chain variable set the name of the network (Kovan, Core, xDAI, etc.). Will be used as part of the infrastructure resource names.
env_vars represents the set of environment variables used by BlockScout. They are available here.
One can define
BULD_* set of the variables, where asterisk stands for any environment variables. All variables defined with
BUILD_* will override default variables while building the dev server.
aws_secret_key is a credentials pair that provides access to AWS for the deployer; You can use the
aws_profile instead. In that case, AWS CLI profile will be used. Also, if none of the access key and profile provided, the
default AWS profile will be used. The
aws_region should be left at
us-east-1 as some of the other regions fail for different reasons;
backend variable defines whether deployer should keep state files remote or locally. Set
backend variable to
true if you want to save state file to the remote S3 bucket;
upload_config_to_s3 - set to
true if you want to upload config
all.yml file to the S3 bucket automatically after the deployment. Will not work if
backend is set to false;
upload_debug_info_to_s3 - set to
true if you want to upload full log output to the S3 bucket automatically after the deployment. Will not work if
backend is set to false.
bucket represents a globally unique name of the bucket where your configs and state will be stored. It will be created automatically during the deployment;