...
Incredibuild Cloud can be deployed in multiple modes and setups, depending on your deployment strategy. Here are a few examples of how Incredibuild users have chosen to deploy on AWS:
...
Setup within a single availability zone, using a mix of EC2 instance types:
...
...
Using Incredibuild Cloud to support employees working from home (WFH) over multiple regions and at multiple build farms:
...
...
Multi-AZ Fault Tolerant Architecture
In the multi-AZ fault tolerant deployment option, helpers are situated across multiple availability zones to ensure high availability and fault tolerance.
...
Single AZ Architecture (Development and Testing)
Incredibuild Cloud may also be deployed in a single availability zone. The data flow and architecture components are the same as the ones highlighted above.
...
Deployment
The onboarding process is in fact part of the user’s registration to the Incredibuild Cloud service. Completion of this step should create all resources that will grant Incredibuild Cloud service permissions to create the resources on behalf of the customer under a selected subscription. The permissions needed include: network, storage, EC2 instances, security, billing etc.
...
In this section, we discuss Incredibuild Cloud’s default configuration deployed pursuant to this guide, AWS general best practices, and options for securing your solution on AWS.
...
Communication between the coordinator and the helper machines
Incredibuild uses the TLS 1.2 cryptographic protocol, through the usage of the OpenSSL library. The cipher used by default is decided during negotiation by the TLS infrastructure, depending on which ciphers are supported on both sides of the communication link. In our case, one of the AES suites of ciphers is used.
The following diagram demonstrates the flow for any API authentication from coordinator located on Customer’s LAN to Incredibuild Cloud service located in Incredibuild Cloud environment as well as the authentication flow from IB cloud service to the Customer’s cloud to perform provisioning actions.
...
...
Amazon Certificate Manager SSL/TLS Certificates
In order to use Incredibuild’s self-signed certificate, see Adding IncrediBuild Self-Signed Certificate to Your API Client Tool.
...
Logging
We recommend turning logging on during the initial testing as well as when troubleshooting. However, since logging has an impact on performance, it is not recommended to be activated during production use. Read our guide for instructions
...
Incredibuild’s auto-scaling allows companies to define the instance types and deployment sizing according to the workload demands. We strongly recommend running Incredibuild on a test environment first to assess the desired sizing prior to deployment.
7. Deployment Assets
...
Deployment Options
Incredibuild Cloud can be deployed as a hybrid setup to burst to cloud when on-prem resources are insufficient, or as a pure cloud on AWS. The latter can be deployed across one or more availability zones, using both spot and on-demand instance types.
...
Deployment Assets (Recommended For Production)
Incredibuild Cloud deployment is being orchestrated by the coordinator machine. No AWS assets are needed aside from the EC2 machines and anything else which may be required by your company’s policy (eg VPN).
8. Backup and Recovery
...
Instance Failure
Unhealthy instances are detected and terminated by the Incredibuild coordinator. Temporary performance degradation may occur, however users will not experience any data loss and no admin intervention is required. If you encounter persistently unhealthy instances, please contact our support at support@incredibuild.com.
...
Coordinator machine redundancy
Incredibuild Cloud offers an automated redundancy for the coordinator machine which automatically gets activated upon coordinator failure. Once the backup machine has been set up, follow Incredibuild Cloud configuration instructions to define the backup machine for automated redundancy.
...
Helper machine redundancy
Incredibuild Cloud allows setting up an automated helper machine redundancy which follows a set of fallback instructions across multiple spot instance types and on-remand machines. As a result, any failure to allocate a certain machine type as a helper, will automatically ball back to the next machine type as configured by the user.
...