# Services : GCloud : Overview ## Projects & Resources All **resources** must exist within a particular **project**. First create a project, then create resources within that project. Projects have a user-defined **Name** (ex: “backend-prod”), a auto-generated unique **ID** based on the Name (ex: “backend-prod-425315”), and an auto-generated **Number** (“975038920339”). #### Locations It seems nearly every resource exists within a particularly **location** — meaning either a **region** or a **zone** (subdivision of region). In other words, whenever you create or reference a resource, you must explicitly state the location. ``` region -> us-central1 zone -> us-central1-a ``` #### User Interfaces Resources can be created and managed via: - Google Cloud Console (web UI) - REST API - RPC API - Client Libraries - CLI (`gcloud`) ## Artifact Registry A place to store container **images** so that you can run them on Cloud Run. To use it, first create a **repository** resource by specifying a name, location, and repository-format (docker). Then you can add images by building them with Cloud Build using image URLs that incorporate the repository URL: ``` Repository URL: us-central1-docker.pkg.dev/backend-prod-425315/proj-repo Image URL: us-central1-docker.pkg.dev/backend-prod-425315/proj-repo/backend:v23 ``` ## Cloud Run Run managed **services** (HTTPS) and **jobs** from container images stored in Artifact Registry (or Docker Hub). Services _must_ speak HTTPS on a port and should run indefinitely. Jobs must _not_ listen on a port, and must eventually end — returning zero for success or non-zero for failure. Containers are configurable in terms of CPUs (1-8), memory (512mb-32gb), env vars, CMD, and ENTRYPOINT. (For jobs, CMD is overrideable per-execution.) Logs are automatically gathered by Cloud Logging. ### Services Services are created by specifying a name, image, and optional config. The first deploy (`gcloud run deploy`) creates the service, and every update (`gcloud run services update`) creates a new **revision** of that service. When a revision is executed, the result is one or more running **instances** of that revision. If the new containers start listening on the service port, traffic is routed to them and the previous revision is stopped. If the new revision’s containers don’t start listening within 240 seconds, they are stopped, and the service is rolled back to the previous revision. > [!NOTE] > Revision names are based on the service name and revision number. For example, the fourth deploy to the “web” service might be named “web-00004-2zx”. **Features** - assigned a unique HTTPS endpoint on `.run.app` domain (public or private) - manages TLS, supports WebSockets - automatically scales instances as needed (from 0 up) (config: min/max, cpu-always-attached) - configurable container concurrency (1-1000) and request timeout (300s-3600s) - can front with CDN via Cloud CDN or Firebase Hosting - can explicitly control traffic-splitting between revisions for gradual rollout ### Jobs Jobs are created by specifying a name, image, and optional config. Once created, jobs can be executed, resulting in one or more running instances of that image. Jobs are are subdivided into **tasks** to facilitate parallelization. The “tasks” param defaults to 1 (one job = one task), but if you set it to a larger number, Google will run multiple containers with the same command and args but env var `CLOUD_RUN_TASK_INDEX` set to the task index value (0 .. tasks-1). You can limit the number of concurrent container executions using `--parallelism`. **Features** - configrable: task retries (0..10), parallelism - overridable per-execution: CMD, env vars, tasks (1-10,000) task timeout (1s-24hr) - triggerable from Cloud Scheduler via Google-hosted HTTP endpoint ## Cloud Scheduler Create named **cron jobs** (different from Cloud Run jobs) that run on a **schedule** to deliver a **payload** to a **target** (Pub/Sub or HTTP endpoint). For HTTP endpoints, supports retries (0-5) with exponential backoff (configurable) until the next scheduled run time. **Features** - “at least once” delivery (jobs must be idempotent in case of repetition) - can be used to invoke Cloud Run jobs via a Google-hosted HTTP endpoint - for HTTP: configurable method, headers, body ## Cloud Tasks TODO