We looked at the Flannel specific code in the CFCR-Repo and the Flannel-Docs. We focused our research in two directions: What would Flannel do and any mention of a CNI ? What would Flannel do… While narrowing our scope, this was still plenty.Īs a first milestone, we had to find how and where Flannel is utilized within CFCR and how we configure a CNI in Kubernetes and Docker. To get an idea, we started searching for keywords : network/cni/flannel in the releases and deployment manifests we already used: cf-deployment cf-networking-release docker-release kubo-release. To be honest, that was about all we knew… We knew we’re working on exchanging a CNI named Flannel in our CFCR-deployment with a CNI named SILK that is used on DIEGO-Cells. This is where it gets complicated and where we hit the first bumps in the road. Hacking it into obedience, it’s just a CNI they said… We created two pipelines: CF and CFCR and let Concourse take care of the rest. Once again we combined Bosh-BBL and BUCC to quickly deploy our infrastructure and base environments. Baby steps…Ī few things were clear and a good place to start: Furthermore, we’re going to have to touch code in several places and projects to achieve our goal.
We quickly realized that we’re not just going to change a few lines to make it work. Here is the ci, here are the wrappers, and finally here is the customized cfcr-release.Īs with every new codebase you touch: In the beginning, there was confusion. If you just stumbled upon this, it might be a good idea to check out the first blog-post explaining the project. Welcome back to the second part of SILK for CFCR. By Konstantin Kiess Part Two: Approaching the problem without rewriting existing code
0 kommentar(er)
