This content originally appeared on DEV Community and was authored by Javier Sepúlveda
In the first blog of crossplane, a glimpse was taken to a crossplane from an understanding of the key concepts, her definition and make some examples for understanding each component.
Can read above.
In the last blog, work was an exercise of how to deploy a simple app using wordpress with crossplane and creating each layer using Managed resources, that is well, but no is a best practice.
Can read above.
Now is time for applying the best practices using crossplane and make your APIs with a higher level more far from a simple Managed Resources.
Composition and Composite Resource Definition are the configurations that are used to compose a higher-level API.
The composite resource defines the schema of the new custom API, it is a definition of a new CRD and the Composition is the bridge between the new CRD schema and the existing managed resources. When the CompositeResourceDefinition and the Composition are done, it is the moment to start provisioning the infrastructure using a resource claim object.
All this together allow us building reusable infrastructure for our teams, imagine something like to build many APIs or patterns and the teams in a self-service model adding her needs in the car to finally build an app.
Requirements
- Kubernetes cluster (Minikube)
- Helm version v3.13.1 or later
- Crossplane
- programmatic access AWS
Step 1.
This blog assumes that you have all requirements completed and assume that you have installed the providers and the ProviderConfig used in the last blog.
If you have any doubt, please check the last post.
Step 2.
validating the providers.
kubectl get all -n crossplane-system
kubectl get providerconfig
With this validation, the environment is ready to provision AWS resources using compositions.
Step 3.
It is necessary to know how CompositeResourceDefinition works. Please check this link for more info.
This is the first CompositeResourceDefinition for defining a higher level API for a VPC in AWS.
Download the repository for creating the resources.
segoja7
/
crossplane_compositions
This is a copy of crossplane_app_aws but using compositions
crossplane_compositions
This is a copy of crossplane_app_aws but using compositions
apiVersion: apiextensions.crossplane.io/v1
kind: CompositeResourceDefinition
metadata:
name: xvpcs.segoja.example # plural.group
spec:
group: segoja.example #api group
names:
kind: Xvpc #singular name
plural: xvpcs #plural name
versions:
- name: v1alpha1 #Define the versions from alpha to pdn or deprecated
served: true #version actively
referenceable: true #indicates which version of the schema Compositions use
schema: # OpenAPI schema
openAPIV3Schema:
type: object
properties:
spec:
type: object
properties:
parameters:
type: object
properties:
cidrBlock:
type: string
#default: "10.0.0.0/16"
enableDnsHostnames:
type: boolean
default: true
enableDnsSupport:
type: boolean
default: true
region:
type: string
default: "us-east-1"
required:
- region
In this point the compositeResourceDefinition is a new CRD and the Composition like the new controller waiting for a claim for creating the resource according to definitions.
Note: The section patches is very important because is the unique place that is available for that the user could be personalized the resource, in this case the user could be define the name of the vpc and the cidrblock.
apiVersion: apiextensions.crossplane.io/v1
kind: Composition
metadata:
name: xvpc-composition
spec:
compositeTypeRef: #specific version defined in the
apiVersion: segoja.example/v1alpha1
kind: Xvpc
resources: #Array with the list of Managed Resources
- name: vpc
base: #Resource template
apiVersion: ec2.aws.upbound.io/v1beta1
kind: VPC
spec:
forProvider:
cidrBlock: 172.0.0.0/16
enableDnsHostnames: true
enableDnsSupport: true
region: us-east-1
tags:
app: vpc-wordpress
ManagedBy: crossplane
providerConfigRef:
name: segoja7
patches: #subattributes
- fromFieldPath: "spec.parameters.cidrBlock"
toFieldPath: "spec.forProvider.cidrBlock"
- fromFieldPath: "metadata.name"
toFieldPath: "spec.forProvider.tags.Name"
- fromFieldPath: "metadata.name"
toFieldPath: "metadata.annotations['crossplane.io/external-name']"
The claim allows a user to create the resource that was defined in the compositeResourceDefinition and Additionally, the user could create that resource in the namespace that was assigned for him.
apiVersion: segoja.example/v1alpha1
kind: Xvpc #singular claim name in the compositeResourceDefinition
metadata:
name: vpc-wordpress-claim
namespace: default
spec:
parameters: #Parameters in the composition
cidrBlock: 192.178.0.0/16
Step 4
At that time the first API was build.
kubectl apply -R -f resources/network/vpc/
The new API xvpcs, to create vpcs.
The compositeResourceDefinition
The composition
The claim for creating a vpc.
This is the vpc in console, as you can see, the vpc have DNS hostnames and DNS resolution enabled by default, the only values that accept the compositions are cidrblock and vpc_name, in this way it is possible to adjust the compositions to the needs of each company or teams.
Conclusion: This is a practical example of how to quickly enable product teams or developers to use infrastructure or apps quickly, without coding, just using configurations, the platform teams abstracts and encapsulates all the complexity.
Thanks for reading this post, let me know if you have any question or comment.
This content originally appeared on DEV Community and was authored by Javier Sepúlveda
Javier Sepúlveda | Sciencx (2024-10-08T20:47:52+00:00) Self-Service : Building and Enabling APIs with Crossplane and AWS. Retrieved from https://www.scien.cx/2024/10/08/self-service-building-and-enabling-apis-with-crossplane-and-aws/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.