HI channel. I'm setting up a fleet instance in GCP...
# fleet
m
HI channel. I'm setting up a fleet instance in GCP - wondering if there's any prior art on using GitHub Actions/runners to automatically build fleet installers and push them to storage buckets beyond just the fleet repo examples.
z
hey @Magneto have you seen the newest GCP guide? done via terraform
it's fairly new to us so we don't have a ton of subject matter expertise here, but feel free to throw specific questions in the channel. will also wait for any community members to jump in šŸ™‚
m
I have not, thank you. I was running an updated and mangled copy of the old stack I found, before the module existed.
šŸ™Œ 1
z
This is fresh! Two months old. Share any feedback if you don't mind šŸ™‚
m
I will rebuild the entire thing with the new stack šŸ™‚
šŸ™Œ 1
m
two pieces of feedback so far: • this appears to create a classic application load balancer, and google is pushing towards global. still exploring the terraform syntax for creating one, will update here with notes • depending on the order in which things are applied, for a BYO project, the private-service-access is looking for a network that might not exist yet. I had to add
depends_on = [module.vpc]
to line ~13 of
./gcp/byo-project/database.tf
to resolve the error of the network not being found when running
terraform plan
āœ… 1
z
@Jorge Falcon fyi ^
šŸ‘€ 1
m
Two more followups: • there still does not appear to be clear documentation or implementation for building installers via GCP. Am I missing something obvious? The bucket gets created but no installers that I can find. Doing this via GitHub Actions and then uploading to the Storage Bucket would make the most sense to me, but I don't see any obvious integrations. • the CloudSQL instance does not appear to follow best practices (according to Google) - I wonder if it's possible to do so and still have the application work as expected?
(specifically the password policies and the encrypted connections - auditing would seem to not make sense at this scale and is an organizational choice I think)
j
@Magneto Thanks for following up, sharing your experience and feedback with the GCP module. The refreshed module is still relatively fresh like @Zay Hanlon mentioned. I'm not hands-on familiar with the GCP modules just yet, but I think you have some valid points. With regards to your questions/suggestions from earlier today • installers - do you mean building the fleet package with fleetctl and storing and distributing from the bucket? I ask because the installers bucket that the module creates, I believe is intended for Fleet software installers that are either uploaded via the Fleet UI or through gitops. • cloudsql - from the screenshot, I think the Google recommendations make sense and, from what I can see, the cloudsql module that we defined consumes the hashicorp cloud sql module, which supports configuring connections over TLS, password policies, and auditing. Though I'm not sure how the current implementation of our GCP module would react to implementing some of those items, Fleet should support the connection over TLS and the password policies. I think it would be totally worth while to submit an issue against the fleet-terraform github repository, so that we can dive deeper and implement the items that are being flagged (and potentially other items that we may not be aware of yet)
s
using GitHub Actions/runners to automatically build fleet installers and push them to storage buckets beyond just the fleet repo examples.
I was actually thinking about this today and how it would be useful to have a github action which builds fleetd/orbit packages. In my case I'd probably prefer it as a Github release artifact rather than in a GCP bucket, but its a similar problem. That said: we don't build fleetd/orbit often since it auto updates itself so for us this might not be worth automating.