In this opportunity is the moment to know with more detail as deployed resources in AWS using resource definitions in crossplane, In the last post we talked about some definitions of crossplane, you can check them in the following link.
.
Requirements
- Kubernetes cluster (Minikube)
- Helm version v3.13.1 or later
- Crossplane
- programmatic access AWS
Step 1.
First, create a profile in minikube
minikube start -p crossplane
With minikube running is moment for install Helm and crossplane, check this link.
with the profile of minikube created and helm and crossplane running it is needed to create a txt file, for this case the document name is profile.txt
[default]
aws_access_key_id = <Your access key id>
aws_secret_access_key = <Your secret access key>
when the txt file is created it is necessary created a generic secret.
kubectl create secret generic aws-secret -n crossplane-system --from-file=creds=./profile.txt
Step2.
Installing a provider
installing provider, in this case providers for rds, ec2, efs and elb.
apiVersion: pkg.crossplane.io/v1
kind: Provider
metadata:
name: provider-aws-ec2
spec:
package: xpkg.upbound.io/upbound/provider-aws-ec2:v1.12.0
---
apiVersion: pkg.crossplane.io/v1
kind: Provider
metadata:
name: provider-aws-rds
spec:
package: xpkg.upbound.io/upbound/provider-aws-rds:v1.12.0
---
apiVersion: pkg.crossplane.io/v1
kind: Provider
metadata:
name: provider-aws-efs
spec:
package: xpkg.upbound.io/upbound/provider-aws-efs:v1.12.0
---
apiVersion: pkg.crossplane.io/v1
kind: Provider
metadata:
name: provider-aws-elbv2
spec:
package: xpkg.upbound.io/upbound/provider-aws-elbv2:v1.13.0
When the provider is installed is time to create an providerconfig, and associated the secret created for autenticated with aws.
Configuring the provider
apiVersion: aws.upbound.io/v1beta1
kind: ProviderConfig
metadata:
name: segoja7
spec:
credentials:
source: Secret
secretRef:
namespace: crossplane-system
name: aws-secret
key: creds
In this case, it is using the key from secret with the name creds.
Note: for this lab it is using a credential, but for other environment type is more recommend used roles.
Architecture
This is a simple wordpress app with high availability.
Step3.
Download the repository for create the resources.
You can check the code in the link above, all the resources are in stack and with the kubectl apply command in a matter of minutes all the services will be deployed in AWS and with the wordpress application ready to install.
A little of spam
kubectl apply -R -f resources/
instance.ec2.aws.upbound.io "ec2-wordpress" created
instance.ec2.aws.upbound.io "ec2-wordpress-2" created
elb.elb.aws.upbound.io "wordpress-elb" created
attachment.elb.aws.upbound.io "attachment-elb-wordpress" created
subnetgroup.rds.aws.upbound.io "wordpress-subnetgroup" created
instance.rds.aws.upbound.io "wordpress-dbinstance" created
securitygroup.ec2.aws.upbound.io "ec2securitygroup" created
securitygroupingressrule.ec2.aws.upbound.io "http-rule" created
securitygroupegressrule.ec2.aws.upbound.io "outbound-rule-ec2-wordpress-sg" created
securitygroup.ec2.aws.upbound.io "efssecuritygroup" created
securitygroupingressrule.ec2.aws.upbound.io "app-to-efs-rule" created
securitygroupegressrule.ec2.aws.upbound.io "outbound-rule-efs-sg" created
securitygroup.ec2.aws.upbound.io "elbsecuritygroup" created
securitygroupingressrule.ec2.aws.upbound.io "world-to-elb-rule" created
securitygroupegressrule.ec2.aws.upbound.io "outbound-rule-elb-wordpress-sg" created
securitygroup.ec2.aws.upbound.io "rdssecuritygroup" created
securitygroupingressrule.ec2.aws.upbound.io "app-to-db-rule" created
securitygroupegressrule.ec2.aws.upbound.io "outbound-rule-rds-sg" created
vpc.ec2.aws.upbound.io "two-tier-vpc-app" created
subnet.ec2.aws.upbound.io "database-private-subnet-az1" created
subnet.ec2.aws.upbound.io "database-private-subnet-az2" created
subnet.ec2.aws.upbound.io "app-private-subnet-az1" created
subnet.ec2.aws.upbound.io "app-private-subnet-az2" created
subnet.ec2.aws.upbound.io "public-subnet-az1" created
subnet.ec2.aws.upbound.io "public-subnet-az2" created
routetable.ec2.aws.upbound.io "public-route-table" created
routetable.ec2.aws.upbound.io "private-route-table" created
internetgateway.ec2.aws.upbound.io "internetgateway" created
eip.ec2.aws.upbound.io "eip-nat-gateway-az1" created
natgateway.ec2.aws.upbound.io "nat-gateway-az1" created
routetableassociation.ec2.aws.upbound.io "private-route-table-dbassociation1" created
routetableassociation.ec2.aws.upbound.io "private-route-table-dbassociation2" created
routetableassociation.ec2.aws.upbound.io "private-route-table-appassociation1" created
routetableassociation.ec2.aws.upbound.io "private-route-table-appassociation2" created
routetableassociation.ec2.aws.upbound.io "public-route-table1" created
routetableassociation.ec2.aws.upbound.io "public-route-table2" created
route.ec2.aws.upbound.io "publicroute" created
route.ec2.aws.upbound.io "privateroute" created
filesystem.efs.aws.upbound.io "efs-wordpress" created
accesspoint.efs.aws.upbound.io "efs-wordpress" created
filesystempolicy.efs.aws.upbound.io "efs-policy" created
mounttarget.efs.aws.upbound.io "efs-mounttarget-az1" created
mounttarget.efs.aws.upbound.io "efs-mounttarget-az2" created
With all resouces created is moment of install wordpress, for brevity this step is skiped but you can check the dns name for validating the site and retrieve the rds values for installing wordpress.
Troubleshooting
In some cases the resources are not created, when the resource is in state ready=false the resource is not deployed and is moment for revise the specs for the desired state of the resource.
When the spec of the resource is modified, it is moment for apply the resource again.
Additional is posible make a list of all resources and verify it is status.
kubectl get managed
Cleanup
kubectl delete -R -f resources/
instance.ec2.aws.upbound.io "ec2-wordpress" deleted
instance.ec2.aws.upbound.io "ec2-wordpress-2" deleted
elb.elb.aws.upbound.io "wordpress-elb" deleted
attachment.elb.aws.upbound.io "attachment-elb-wordpress" deleted
subnetgroup.rds.aws.upbound.io "wordpress-subnetgroup" deleted
instance.rds.aws.upbound.io "wordpress-dbinstance" deleted
securitygroup.ec2.aws.upbound.io "ec2securitygroup" deleted
securitygroupingressrule.ec2.aws.upbound.io "http-rule" deleted
securitygroupegressrule.ec2.aws.upbound.io "outbound-rule-ec2-wordpress-sg" deleted
securitygroup.ec2.aws.upbound.io "efssecuritygroup" deleted
securitygroupingressrule.ec2.aws.upbound.io "app-to-efs-rule" deleted
securitygroupegressrule.ec2.aws.upbound.io "outbound-rule-efs-sg" deleted
securitygroup.ec2.aws.upbound.io "elbsecuritygroup" deleted
securitygroupingressrule.ec2.aws.upbound.io "world-to-elb-rule" deleted
securitygroupegressrule.ec2.aws.upbound.io "outbound-rule-elb-wordpress-sg" deleted
securitygroup.ec2.aws.upbound.io "rdssecuritygroup" deleted
securitygroupingressrule.ec2.aws.upbound.io "app-to-db-rule" deleted
securitygroupegressrule.ec2.aws.upbound.io "outbound-rule-rds-sg" deleted
vpc.ec2.aws.upbound.io "two-tier-vpc-app" deleted
subnet.ec2.aws.upbound.io "database-private-subnet-az1" deleted
subnet.ec2.aws.upbound.io "database-private-subnet-az2" deleted
subnet.ec2.aws.upbound.io "app-private-subnet-az1" deleted
subnet.ec2.aws.upbound.io "app-private-subnet-az2" deleted
subnet.ec2.aws.upbound.io "public-subnet-az1" deleted
subnet.ec2.aws.upbound.io "public-subnet-az2" deleted
routetable.ec2.aws.upbound.io "public-route-table" deleted
routetable.ec2.aws.upbound.io "private-route-table" deleted
internetgateway.ec2.aws.upbound.io "internetgateway" deleted
eip.ec2.aws.upbound.io "eip-nat-gateway-az1" deleted
natgateway.ec2.aws.upbound.io "nat-gateway-az1" deleted
routetableassociation.ec2.aws.upbound.io "private-route-table-dbassociation1" deleted
routetableassociation.ec2.aws.upbound.io "private-route-table-dbassociation2" deleted
routetableassociation.ec2.aws.upbound.io "private-route-table-appassociation1" deleted
routetableassociation.ec2.aws.upbound.io "private-route-table-appassociation2" deleted
routetableassociation.ec2.aws.upbound.io "public-route-table1" deleted
routetableassociation.ec2.aws.upbound.io "public-route-table2" deleted
route.ec2.aws.upbound.io "publicroute" deleted
route.ec2.aws.upbound.io "privateroute" deleted
filesystem.efs.aws.upbound.io "efs-wordpress" deleted
accesspoint.efs.aws.upbound.io "efs-wordpress" deleted
filesystempolicy.efs.aws.upbound.io "efs-policy" deleted
mounttarget.efs.aws.upbound.io "efs-mounttarget-az1" deleted
mounttarget.efs.aws.upbound.io "efs-mounttarget-az2" deleted
Conclusion:
This is a short overview of how to deploy managed resources using crossplane, in the next post we will make a demo to deploy resources in the console but with compositions.
Thanks for reading this post, let me know if you have any question or comment.
Top comments (0)