Automatically provisions an ephemeral development server on Google Cloud Platform. An immutable machine image is built with Packer and deployed on a Compute Engine instance with Terraform, all via Cloud Build.
-
Cloud computing costs money. One aim of this project is to keep costs low by streamlining the create/destroy process, but be aware that this code will provision resources that will incur charges to your billing account. Please read the license (MIT) before proceeding, with emphasis on
"[...] IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, [...]
-
Additionally, this project is still in early development and is not production-ready. Security scans by Snyk detect (as of commit
459f170
), 7 "low severity misconfigurations" in the Terraform design including, possibly non-exhaustively, the following:- SNYK-CC-TF-185: "Google storage bucket does not use customer-managed keys to encrypt data
- SNYK-CC-GCP-271: "Object versioning is not enabled"
- SNYK-CC-GCP-274: "Logging is not enabled on storage bucket"
- SNYK-CC-GCP-461: "Delete protection is disabled"
- SNYK-CC-TF-91: "GCP Compute Firewall allows open egress"
- SNYK-CC-TF-184: "Customer supplied encryption keys are not used to encrypt VM compute instance"
If you don't have an SSH key pair already, generate one (preferably with a high-entropy passphrase):
ssh-keygen -o -a 100 -t ed25519 -C remote-dev
PROJECT_ID
inrun.sh
terraform/env/prod/terraform.tfvars
packer/config.auto.pkvars.hcl
In the remote-dev
repository, run
./run.sh create
Before logging in for the first time, you'll need to go to
https://console.cloud.google.com/security/iap and make sure that IAP is
working properly. Specifically, you'll need a firewall
rule allowing
TCP-protocol ingress to the remote-dev
target from IPv4 source range
35.235.240.0/20. To do so programmatically,
see here.
Then to authenticate and log in, run
# replace us-east1-b, alice@remote-dev, and project-name with your own values
gcloud compute ssh --zone "us-east1-b" "alice@remote-dev" --tunnel-through-iap --project "project-name"
In addition to accessing the new machine this way, you can also use Cloud Code extensions to use your instance as a backend for IntelliJ and VS Code.
For example, if you use a public IP address (which this project avoids
for better security by default), then after installing
the Cloud Code extension for VS Code,
open the command palette (Ctrl/Cmd + Shift + P)
and select Cloud Code: Open in Cloud Shell...
, then select "Home" and your project
ID, and proceed iff the server's fingerprint is correct. From there, ./run.sh create
(if you hadn't already) and then SSH into your machine.
If you use a private IP address, follow the instructions in this article to set up VS Code. The same method may work for IntelliJ, but is untested. On Windows, this article may be useful, but is also untested.
Caution: the keyword here was ephemeral: this action will delete the whole environment and all the data inside it. Push your changes to whatever you were working on before destroying your system.
In the remote-dev
repository, run
./run.sh destroy
This project (being derivative of 2n3g5c9/remote-dev) is licensed under the MIT License. See the LICENSE file for details.