Compiler #

This page goes through the three services involved in compiling user code:

• cc-compiler-master
• cc-compiler-servant
• cc-compiler-slave

This deployment is relatively more complex due to the amount of moving parts and security considerations:

• cc-compiler-servant-packer
• Compute Engine
• Instance Template
• Managed Instance Group
• Cloud Monitoring
• Serverless VPC connector
• Cloud Run

Master #

The cc-compiler-master must be able to connect to cc-compiler-servant through a VPC. As master is deployed on Cloud Run, this is only possible with a Serverless VPC connector.

Servant #

cc-compiler-servant is deployed on a Compute Engine and and is regarded as semi zero trust. The servant still reports data to Cloud Monitoring and also modifies the Mongo servants collection, so it’s not completely zero trust.

Deploying the servant involves several issues:

• CI/CD
• Passing secrets

It’s unreasonable to update the Compute Engine image every time the servant/slave is updated, so everything must be automated to a reasonable extent.

The image for servant is generated by the cc-compiler-servant-packer project, and rebuilds are triggered when the test branch servant/slave is updated. For releases, the a tag must be manually made in the packer repository, and must be made AFTER the Docker images for servant/slave are updated.

When the image is built, the build machine uses the GitLab CI service account, which has been granted permissions to access secrets. The build machine also pulls the Docker images for servant and slave.