Cool! Everything is here:
https://github.com/apache/airflow/tree/master/scripts/ci/in_container/kubernetes
In short:
In "kubernetes" dir:
setup_kind_cluster.sh + kind-cluster-conf.yaml -> they are
use to create a kind Kubernetes cluster.
In "docker" subdir:
rebuild_airflow_image.sh -> rebuilds the CI image that we use for
testing and adds bootstrap.sh and airflow-test-env-init.sh so that the CI
image can be run as pod.
In "app" sub-folder we have - potgres.yaml, secrets.yaml and volumes.yaml -
with resource definitions.
We also have there deploy_app.sh that processes the templates
(below) and deploys all the resources to the cluster. It has a bit of logic
because we have to make sure that we are pulling DAGs from the right branch
(the branch we are currently running tests on) and there is a logic to wait
until everything is deployed and responding.
In "app/templates" we have airflow.template, and configmaps.template that
are used to generate the right airlfow.yaml and configmaps.yaml that should
be deployed to Kubernetest by the deploy_app.sh
We run the tests in two different modes "git_sync" - where the DAGs are
downloaded from the branch being tested (hence the logic) and "persistent"
where the DAGs are pre-baked in the image we prepare during
"rebuild_airflow_image.sh"
My plans are to build and use the production image instead of CI one for
those tests. That would make it much faster (CI image is huge). I also plan
to move kind cluster creation outside of the container. Right now we have
docker socket mapped inside the container and we run all the "kind create"
etc. from within container - but it has some problems as we tried to test
it in Github Action (namely DNS was not properly configured in Github
Actions if we created
Kind in this way). So my plan was to allow to do both - create kind
cluster in container (useful for Breeze and local testing) or to create
Kind cluster (or simply use from outside if available).
I think as the next step it should be that for both types of tests
(persistent and git_sync) we simply use the helm chart to install it rather
than the complex template + deploy_app.sh + custom resources - they are
pretty much doing what helm chart should give us out-of-the-box.
J.
On Thu, Mar 26, 2020 at 3:20 PM Greg Neiheisel <g...@astronomer.io> wrote:
> Yep, we can absolutely pull it into the airflow repo. We've also been
> building up a test suite that currently runs on CircleCI and uses kind
> (Kubernetes in Docker) to test several kubernetes versions with some
> different settings. Right now we're mostly testing the different executors
> since that has the biggest impact on what gets deployed, but that can be
> expanded.
>
> What CRDs are currently being used to run Airflow for the tests?
>
> -
>>
> Jarek Potiuk
Polidea <https://www.polidea.com/> | Principal Software Engineer
M: +48 660 796 129 <+48660796129>
[image: Polidea] <https://www.polidea.com/>
