Create das-server-dev && Add instructions on dev-test loop

[todor-ivanov]

Building a testing container and runtime environment for das-server && Adding dev-test loop instructions
In relation to: dmwm/das2go#77

[vkuznet]

Todor, I'm not sure what do you want to accomplish here but if your goal to deploy das in dev environment there are multiple ways to achieve that:

1. you may choose to use existing k8s yaml file and build your own das image. For that you may modify to use alpine image instead of distroless and keep separate Dockerfile for it or even modify existing Dockerfile and pass build argument to choose which final image to use alpine or distroless. This way you can use existing k8s manifest files and you own dev image
2. Do not use k8s at all, as static exetuable allows you to run DAS on your VM/laptop. I alwyas used this way as it much easier. The only requirement is to install mogno and use DAS proper maps.
3. Your instructions are fine but require additional clarifications:

• there is no standard k8init command (it is most likely yours) and if neither kctl (there is official kubectl command though). Therefore your instructions at least incomplete and at most not portable to another human.
• you are making assumption in step 2.2 that you already have existing das-server which may not be the case, e.g. if I want to deploy das to fresh k8s cluster.
• you setup port-forwarding in step 2.4 although it is not what we use in CMS k8s setup. Your choices are either to setup your own APS, or change manifest to use NodePort instead ClusterIP. I understand that port fowarding works too but it is yet another diverse path which another maintainer need to know.
• in step 3.1 you must ensure that you build static executable on correct architecture. For instance, I work on macOS but deploy on Linux. You must use proper Go build flags/env variables such as GOARCH=amd64 GOOS=linux CGO_ENABLED=0 for all executables. The Makefile I made takes care of that but if you invoke go build you should take care of that.

4. In step 3.2 you copy local executable to image. Therefore you should take care of OS compatibility. A better approach in my view is to run das locally without k8s and all of these steps, or build your image with dev tools, e.g. you can start with golang image which provide go compiler and therefore you may login to this image and rebuild das if you want to use it for your dev tasks.
5. If you want fully dev environment you should learn how to deploy it from top to bottom, i.e. install APS as daemon set instead of ingress. Making changes to how routing works is not a best approach. The APS deployment is trivial (again it is static go executable) and its rules exists. You can have your own APS with /das route and nothing else deployed to your k8s server. And, it will provide fully compatible with cmsweb/cmsweb-testbed environment without any modifications you introduced in this step such that you can have https://your-cluster/das which will work identically as cmsweb/cmsweb-testbed. If you need help with that you can ask cmsweb operator to setup APS for you in your dev cluster.

Bottom line is that even though proposed solution is fine (despite being used your own aliases) it is not aligned with cmsweb procedure and if you use it on your own it is ok, but if you want to delegate it to someone else afterwards it is not compatible at least.

[todor-ivanov]

Hi @vkuznet, having DAS deployed locally does not provide a full dev/test environment, even though the executable is static and runable. I still need the rest of the surroundings linked as well, and also the redirection of the ingress so that I can substitute the running application with whatever I have just compiled so I can test how it behaves with real data. I need an environment with access to services as close as possible to the production one. Hence the approach of reusing the testbed cluster and the exact mimicry of the testbed runtime from the distroless container into one to which I have full access, while only substituting the executable for single code changes. This is an iterative process which is to be followed, until I reach a code feasible and stable enough to create a tag and then go through the long path of creating and pushing images upstream. Because this path is not a developer's path, no matter how strong anybody tries to popularize it. This is not a path for a developer who follows a fine grained dev-build-test cycle of work. I simply cannot go through all that madness of creating images on every single line of code change. Hence why I did not chose the so called full dev deployment, that you are talking about. Not because I have not learned it. It just does not fit my needs and dev cycle.

BTW those instructions are perfectly well applicable to any deployment within one of the developers' clusters, with the APS frontend routed to one of the dev clusters e.g. cmsweb-test1.ch/das. The k8 environment doesn't matter there.

About:

you setup port-forwarding in step 2.4 although it is not what we use in CMS k8s setup.

This is not a port-forward for the service to be used while running. This is just a temporary step of forwarding your current local host's port to the port exposed by the pod, so that at this stage one can just check/validate that the so set container is up and running. If I need to be honest this step must go after the first application deployment step or after the stop of mangling the service's app-selector. Otherwise there is no application yet deployed that listens to this port at this stage. I'll move it.

About the architecture the executable is built for - you are correct. I just suppose, that who ever is to follow such a hacky way of paving one's path through the environment would be able to recognize the need for the correct architecture to build for.

The actual cycle I am targeting here (and which I already tested and is doing the job perfectly) is as follows:

• bring up a hollow dev container with empty executable
• redirect the service ingress by changing the app-selector so that it starts pointing to your new and still empty container
• investigate/code in your local tree - use AI tools for assistance if you'd like (no pushes, no commits, no tags or whatever upstream)
• build locally for the proper arch you are about to test
• push the binary into the container
• test/validate with real data
• repeat until you reach code quality satisfactory level
• commit/push upstream, tag, create images, redeploy fresh

P.S. I'll change the instructions from using my aliases to the official tool names.

[todor-ivanov]

Hi @vkuznet, I think I have addressed most of your comments with my latest change. And added some clarifications on the usefulness of this procedure. Please take another look.