crossplane / stack-gcp-sample Goto Github PK

A Crossplane resource pack for a minimal GCP setup

Dockerfile 4.83% Makefile 4.64% Shell 90.53%

stack-gcp-sample's Introduction

GCP Sample Stack

You can use this stack to spin up a private network as well as resource classes that will let you provision resources in that network.

Installation

Requirements:

Crossplane should be installed.
GCP Provider should be installed and its version should be at least 0.7.0

If you have crossplane-cli installed, you can use the following command to install:

# Do not forget to change <version> with the correct version.
kubectl crossplane package install --cluster -n crossplane-system 'crossplane/stack-gcp-sample:<version>' gcp-sample

If you don't have crossplane-cli installed, you need to create the following YAML to install:

apiVersion: packages.crossplane.io/v1alpha1
kind: ClusterPackageInstall
metadata:
  name: "gcp-sample"
  namespace: crossplane-system
spec:
  package: "crossplane/stack-gcp-sample:<version>"

Usage Instructions

You can create the following YAML to trigger creation of

Network
Subnetwork
GlobalAddress
Connection
Provider that points to credentials secret reference you supply

and the following resource classes with minimal hardware requirements that will let you create instances that are connected to that network.

apiVersion: gcp.stacks.crossplane.io/v1alpha1
kind: GCPSample
metadata:
  name: test
spec:
  region: us-west2
  projectID: crossplane-playground
  credentialsSecretRef:
    name: gcp-account-creds
    namespace: crossplane-system
    key: credentials

In Crossplane, the resource classes that are annotated with resourceclass.crossplane.io/is-default-class: "true" are used as default if the claim doesn't specify a resource class selector. The resource classes you create via the GCPSample instance above will deploy all of its resource classes as default. If you'd like those defaulting annotations to be removed, you need to add the following to GCPSample instance above:

templatestacks.crossplane.io/remove-defaulting-annotations: true

Build

Run make

Test Locally

Minikube

Run make and then run the following command to copy the image into your minikube node's image registry:

# Do not forget to specify <version>
docker save "crossplane/stack-gcp-sample:<version>" | (eval "$(minikube docker-env --shell bash)" && docker load)

After running this, you can use the installation command and the image loaded into minikube node will be picked up.

stack-gcp-sample's People

Contributors

Stargazers

Watchers

Forkers

muvaf displague rathpc jbw976 hasheddan lukeweber suskin negz prasek

stack-gcp-sample's Issues

stack image is using crossplaneio org

When building the stack in this stack-minimal-gcp repo, the resulting stack image is crossplaneio/stack-minimal-gcp:latest, but the correct docker hub org is actually just crossplane: https://hub.docker.com/orgs/crossplane

Should be an easy fix in https://github.com/crossplaneio/stack-minimal-gcp/blob/master/stack.env#L2

Deleting gcpsamples object deleted provider before other resources

Given the following versions:

stack-gcp-sample v0.6.0-rc.6.gdff52da
provider-gcp v0.10.0-rc.5.g8eea577
crossplane v0.11.0-rc.100.gbc5d311

I created and then later deleted a gcpsamples, expecting all resources to be cleaned up. I see a handful of lingering resources that cannot be deleted and have status similar to the following, where it appears the provider object was deleted before the managed resources could be deleted from GCP:

 - lastTransitionTime: '2020-05-18T23:14:33Z'
      message: >-
        connect failed: provider could not be retrieved:
        Provider.gcp.crossplane.io "jared-2020-05-18-gcp-provider" not found
      reason: Encountered an error during resource reconciliation
      status: 'False'
      type: Synced

Some of the resources lingering in k8s actually don't show up in GPC anymore, so perhaps this is a race where they were deleted from GCP, then before we can do a GET to verify they are really gone, the provider object is deleted? e.g.:

subnetwork delete call to GCP succeeds
provider object deleted from k8s
subnetwork controller does a GET to verify deletion - fails, can't find provider

Not sure if the flow actually works that way though.

Below table shows the objects that all still exist in k8s, while only the VPC object still shows in GCP.

resource	k8s object	gcp
connection	exists	not exists
subnetwork	exists	not exists
network (VPC)	exists	exists
globaladdress	exists	not exists

GKECluster and CloudSQLInstance report: invalid character ''1'' after object key:value pair

After deploying the Wordpress sample app I get the following Sync message on the GKECluster and CloudSQLInstance resources:

status:
  conditions:
    - lastTransitionTime: '2020-05-25T21:28:48Z'
      message: 'invalid character ''1'' after object key:value pair'
      reason: Encountered an error during resource reconciliation
      status: 'False'
      type: Synced

Minimal GCP resource instance failing during reconciliation

After creating an instance of stack-minimal-gcp this is the status.

status:
  conditions:
  - lastTransitionTime: "2020-02-04T17:46:28Z"
    message: 'apply failed: minimal-gcp-instance-connection/ of type servicenetworking.gcp.crossplane.io/v1alpha3,
      Kind=Connection: no matches for kind "Connection" in version "servicenetworking.gcp.crossplane.io/v1alpha3"'
    reason: Encountered an error during resource reconciliation
    status: "False"
    type: Synced

kustomizations not entirely idiomatic

I was pointing my kustomize at the source kustomization for minimal gcp, and got this error:

rawResources failed to read Resources: Load from path gcp failed: 'gcp' must be a file

I investigated a bit more and learned that kustomize expects directories to be under bases, and for all of the entries under resources to be individual files (see this reference).

It seems that we'll want to use bases for the directories and resources only for the individual files.

Reusing the name of a previous minimalgcp can result in a broken connection

This seems to be a behavioral quirk within GCP, but it is easily triggered by this minimal GCP stack. If a Google Cloud Service Networking Connection (connections.servicenetworking.gcp.crossplane.io) is created in a VPC that has ever existed before, then that service networking connection may never make it to the Ready state.

Repro steps:

Install stack-minimal-gcp
Create instance of minimalgcp named test
Wait for everything to be created successfully
Delete minimalgcp instance
Create minimalgcp instance again with same name

Result: The connection instance generated by this stack's controller may not ever make it to the ready state.

Provide self-contained readme overview / getting started in app.yaml and readme.md

Problem

Getting started can be challenging without an overview and basic getting started steps. Having the overview and getting started docs self-contained in the repo's readme.md and the app.yaml ensures that as changes are made in a given repo, the docs can be updated in the same PR, and that published stacks can be self-documenting. Over time this getting started content can be aggregated by https://crossplane.io.

What can we do to help?

Update the app.yaml readme section and readme.md overview / getting started sections with self-contained, high-level (non-CLI specific) overview and getting started steps.

For example: https://github.com/crossplane/provider-gcp follows this pattern today:

embedding self-contained getting started and dependency info (e.g. stack-aws-sample v0.3.0, depends on provider-aws v0.7.1) included in the the app.yaml and readme.md would also help new users:

then later in the readme.md provide more detailed CLI-specific getting started steps, similar to https://crossplane.io/docs/v0.9/stack.html which only covers stack-minimal-gcp in v0.9

for now, link from https://crossplane.io/docs/v0.9/stack.html to each repos readme.md CLI instructions for additional stack types (e.g. AWS, Azure, Alibaba, etc.)

then in the future, we can aggregate each repos readme.md into the https://crossplane.io/docs/