imjasonh/terraform-playground
1
0
Fork 0
mirror of https://github.com/imjasonh/terraform-playground synced 2026-07-08 15:55:17 +00:00
Code Activity

use Chainguard image, update README

Browse source 
Signed-off-by: Jason Hall <jason@chainguard.dev>
This commit is contained in:
Jason Hall 2024-04-18 08:36:47 -04:00
parent b2f2f36804
commit 572d65f3f7
Failed to extract signature
2 changed files with 36 additions and 6 deletions
Download patch file Download diff file Expand all files Collapse all files

34
litestream/README.md
View file

@ -4,4 +4,36 @@ This demonstrates running a Cloud Run service that uses [Litestream](https://lit
It does this by running the Litestream image as a sidecar container in the same pod as the application container, with a shared volume mounted between them.
The bucket configuration is written to a config file appended to the litestream image.
The application container restores the database from the GCS on startup, and Litestream continuously replicates changes to GCS in the background. Instances can scale to zero, and the database will be persisted across restarts.
## Limitations
This hasn't been tested with multiple container instances, and may not work as expected. For now it's limited to one container instance, which can handle 1000 concurrent requests. This may be enough for most apps.
## Why?
Cloud Storage is _really cheap_ -- much cheaper than most alternatives:
### [Firestore](https://cloud.google.com/datastore/pricing#regional_location_pricing)
- storage: $0.15 per GB/month
- reads: $0.03 per 100,000 entities
- writes: $0.09 per 100,000 entities
### [Cloud SQL](https://cloud.google.com/sql/pricing) (MySQL or PostgreSQL)
- storage (SSD): $0.222 per GB/month
- CPU: $32.266 per vCPU/month
- memory: $5.475 per GB/month
### [Cloud Storage](https://cloud.google.com/storage/pricing)
- storage: $0.02 per GB/month
- reads (class B operations): $0.04 per 100,000 operations\*
- writes (class A operations): $0.50 per 100,000 operations
\* Because Litestream only reads and writes to restore and replicate, these operations don't indicate the number of actual reads/writes to the database itself. Reading from the database is a local operation once the data is restored.
Since it's just SQLite, this also supports standard SQL operations and semantics, and can be trivially tested locally without access to a cloud instance.
There are also potentially tenancy benefits to using a separate database for each user, which can be easily achieved with multiple SQLite instances.

8
litestream/main.tf
View file

@ -37,7 +37,7 @@ resource "google_storage_bucket_iam_binding" "binding" {
resource "ko_build" "build" {
importpath = "./"
working_dir = path.module
base_image = "litestream/litestream"
base_image = "cgr.dev/chainguard/litestream"
}
resource "google_cloud_run_v2_service" "service" {
@ -50,9 +50,7 @@ resource "google_cloud_run_v2_service" "service" {
template {
scaling {
max_instance_count = 1
}
scaling { max_instance_count = 1 }
max_instance_request_concurrency = 1000
containers {
@ -68,7 +66,7 @@ resource "google_cloud_run_v2_service" "service" {
}
containers {
image = "litestream/litestream"
image = "chainguard/litestream"
args = ["replicate", "/data/db.sqlite", "gcs://${google_storage_bucket.bucket.name}/litestream"]
volume_mounts {
name = "data"