ENV variables must be configured per chain
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
host_varsfolders, 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_locationis an address of the Terraform binary on the builder;
dynamodb_tablerepresents the name of table that will be used for Terraform state lock management;
ec2_ssh_key_contentvariable is not empty, Terraform will try to create EC2 SSH key with the
ec2_ssh_key_namename. Otherwise, the existing key with
ec2_ssh_key_namename will be used;
instance_typedefines a size of the Blockscout instance that will be launched during the deployment process;
db_subnet_cidrrepresents 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_cidrrepresents 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_namename will be created to take care of BlockScout internal communications;
root_block_sizeis 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/logsof your EC2 instance;
- Each of the
db_*variables configures the database for each chain. Each chain will have the separate RDS instance;
instance_typerepresent the size of the EC2 instance to be deployed in production;
use_placement_groupdetermines whether or not to launch BlockScout in a placement group.
blockscout_repo- a direct link to the BlockScout repo;
branch- maps branch at
blockscout_repoto each chain;
- Specify the
merge_commitvariable if you want to merge any of the specified
chainswith 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
localfor better performance.
chainvariable set the name of the network (Kovan, Core, xDAI, etc.). Will be used as part of the infrastructure resource names.
env_varsrepresents 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_keyis a credentials pair that provides access to AWS for the deployer; You can use the
aws_profileinstead. In that case, AWS CLI profile will be used. Also, if none of the access key and profile provided, the
defaultAWS profile will be used. The
aws_regionshould be left at
us-east-1as some of the other regions fail for different reasons;
backendvariable defines whether deployer should keep state files remote or locally. Set
trueif you want to save state file to the remote S3 bucket;
upload_config_to_s3- set to
trueif you want to upload config
all.ymlfile to the S3 bucket automatically after the deployment. Will not work if
backendis set to false;
upload_debug_info_to_s3- set to
trueif you want to upload full log output to the S3 bucket automatically after the deployment. Will not work if
backendis set to false.
bucketrepresents a globally unique name of the bucket where your configs and state will be stored. It will be created automatically during the deployment;