Thanks for this series! We currently use Terraform but I’ve been very interested in exploring Crossplane as a potential alternative. I’ll definitely be making use of this series when I’m able to dig into the subject properly.
Hi Victor, I would like to suggest next topic. While adopting crossplane with existing infrastructure, I'm wondering about the best approach to import existing cloud resources to crossplane easiest way possible :) Thanks for your work!
@M79L I mean both. I am involved with the Crossplane project and I work for Uoboind so we in that context means Crossplane community or Upbound. I am not yet sure whether it'll be done by the community or as Uobound freemium festure. On the other hand, I will almost certainly add it as a video on this channel.
as always.....good stuff 🚀 Can you indicate what you have in your pipeline for future videos for this series? Not dates, but which topics you plan to visit?
The plan is to wait until one of the features graduates to beta (becomes stable) and add it to this series. In parallel, I will continue publishing "normal" videos and some of the either include crossplane or are focused on crossplane. I'm not yet sure what those will be. Probably something around database as a service...
That depends on whether you mean to create crossplane manifest based on the existing infra or to use crossplane yo take over management of existing infra. The former is on the brainstorming phase and i hope we will start working on it soon. The latter is not s problem at all. If you apply crossplane resources it will always take a look whether that something already exists or not. If it does not exist, it will create it. If it does exist it will take control of it.
I'm making good progress with KCL function for resource composition. I know you like CUE so was wondering if you have used the cue function much and if you liked it or encountered any friction?
I still tend to use go templating function. I define my compositions as CUE and it's easy inside CUE to output parts of it as yaml for go templating. I'm not sure if it's possible to output CUE inside CUE. I haven't used KCL function just yet but I did start using KCL to define compositions themselves.
@@DevOpsToolkit use what you know and works for you I guess. My go templating ain't so hot :-) . I tried CUE but personally found it hard. I think with more time I could get used to it though. A few teething issues with KCL function but issue support so far great. Settled on lightweight yaml for compositions that uses a KCLRun pipeline step sourcing an OCI KCL package. I just focus on the evolution of the KCL code for resources, publish, and update the source oci version in composition when upgrading. Keep up the videos. You've elevated my devops knowledge immensely.
Thank you! Victor, I have to write a lot of yaml ArgoWorkflows manifests for every new application :( Is it possible to use Crossplane to hide ArgoWorkflows complexity and provide simple yaml-file for developers, so they can fill a few lines, and a "thousands" argo worflows manifests would be "generated" ? :)
You can manage any resource with Crossplane (as long as there is a provider with that resource). In case of Kubernetes resources, you can use the Kubernetes Provider (marketplace.upbound.io/providers/crossplane-contrib/provider-kubernetes) which contains, among others, `Object` resource. From there on, you just wrap it all into a Composition and a Definition which creates a CRD. Your users can create a claim based on that CRD with can have any schema you like. I'm doing something similar in this tutorial except that I'm not creating Argo Workflow resources but those required for Atlas Operator and a few other cases. The logic is the same though.
In regards of db scemas Are there ideas for liquibase/ flyway Honestly i dont think those should be in the CP list at all - reminds like when we gave a java dev oppurtunity to write Helm and he/she is like “oh i always wanted to learn golang” and found a way how to do pure golang in Helm Shoudn’t that remain in the container / initcontainer?
In this case, I used Atlas operator. Crossplane is just combining it with other resources and, by doing that, hiding things that do not matter and exposing those that do. You can easily wrap Liquibase or Flyway instead. In all cases it runs in containers and the major difference is that Atlas has CRDs allowing us to define Cars while Liquibase and Flyway did not yet adapt to Kuberneted so they are typically attached as init containers.
Appologies for bad audio quality. We had some issues in this and a couple of previous video. It'll get better in upcoming videos.
Thanks for this series! We currently use Terraform but I’ve been very interested in exploring Crossplane as a potential alternative. I’ll definitely be making use of this series when I’m able to dig into the subject properly.
Thanks for the series ! The videos are super clear and useful :)
Happy to hear that!
Very clear explanation and compelling use case!
Great video! Any plans on a video on how to actually make a custom function in the future?
Not yet sure when I'll get to that part. It'll come. I just can't promise the date.
another great video!
Hi Victor, I would like to suggest next topic. While adopting crossplane with existing infrastructure, I'm wondering about the best approach to import existing cloud resources to crossplane easiest way possible :) Thanks for your work!
We're working on a solution for that. It is not yet ready. I will show it when it is.
@@DevOpsToolkit - when you say "we" you mean "the crossplane project" or you mean next chapter/video of the crossplane tutorial.. Thank you
@M79L I mean both. I am involved with the Crossplane project and I work for Uoboind so we in that context means Crossplane community or Upbound. I am not yet sure whether it'll be done by the community or as Uobound freemium festure. On the other hand, I will almost certainly add it as a video on this channel.
as always.....good stuff 🚀 Can you indicate what you have in your pipeline for future videos for this series? Not dates, but which topics you plan to visit?
The plan is to wait until one of the features graduates to beta (becomes stable) and add it to this series. In parallel, I will continue publishing "normal" videos and some of the either include crossplane or are focused on crossplane. I'm not yet sure what those will be. Probably something around database as a service...
Hi Victor, will there be a Part 6 or is this the end of the series?
I will be adding new parts as new features graduate to beta (get stable APIs).
is it possible to import the current cloud infrastructure created manually into crossplane management?
That depends on whether you mean to create crossplane manifest based on the existing infra or to use crossplane yo take over management of existing infra. The former is on the brainstorming phase and i hope we will start working on it soon. The latter is not s problem at all. If you apply crossplane resources it will always take a look whether that something already exists or not. If it does not exist, it will create it. If it does exist it will take control of it.
I'm making good progress with KCL function for resource composition. I know you like CUE so was wondering if you have used the cue function much and if you liked it or encountered any friction?
I still tend to use go templating function. I define my compositions as CUE and it's easy inside CUE to output parts of it as yaml for go templating. I'm not sure if it's possible to output CUE inside CUE.
I haven't used KCL function just yet but I did start using KCL to define compositions themselves.
@@DevOpsToolkit use what you know and works for you I guess. My go templating ain't so hot :-) . I tried CUE but personally found it hard. I think with more time I could get used to it though.
A few teething issues with KCL function but issue support so far great. Settled on lightweight yaml for compositions that uses a KCLRun pipeline step sourcing an OCI KCL package. I just focus on the evolution of the KCL code for resources, publish, and update the source oci version in composition when upgrading.
Keep up the videos. You've elevated my devops knowledge immensely.
The recent support for KCL functions in Crossplane looks nice to me.
Thank you! Victor, I have to write a lot of yaml ArgoWorkflows manifests for every new application :( Is it possible to use Crossplane to hide ArgoWorkflows complexity and provide simple yaml-file for developers, so they can fill a few lines, and a "thousands" argo worflows manifests would be "generated" ? :)
You can manage any resource with Crossplane (as long as there is a provider with that resource). In case of Kubernetes resources, you can use the Kubernetes Provider (marketplace.upbound.io/providers/crossplane-contrib/provider-kubernetes) which contains, among others, `Object` resource. From there on, you just wrap it all into a Composition and a Definition which creates a CRD. Your users can create a claim based on that CRD with can have any schema you like.
I'm doing something similar in this tutorial except that I'm not creating Argo Workflow resources but those required for Atlas Operator and a few other cases. The logic is the same though.
In regards of db scemas
Are there ideas for liquibase/ flyway
Honestly i dont think those should be in the CP list at all - reminds like when we gave a java dev oppurtunity to write Helm and he/she is like “oh i always wanted to learn golang” and found a way how to do pure golang in Helm
Shoudn’t that remain in the container / initcontainer?
In this case, I used Atlas operator. Crossplane is just combining it with other resources and, by doing that, hiding things that do not matter and exposing those that do. You can easily wrap Liquibase or Flyway instead.
In all cases it runs in containers and the major difference is that Atlas has CRDs allowing us to define Cars while Liquibase and Flyway did not yet adapt to Kuberneted so they are typically attached as init containers.