I have an app with several pods. The foundational pod takes about 2 minutes to start fully but I basically never need to change it. I'm working on other pods and they start in few seconds if the foundational pod is already running. I'm trying to optimize my development lifecycle when I change the code in fast-starting pod and debugging it.
The "Run on Kubernetes" would be great as it watched the changes and re-deploys that fast-starting pod only. However, I can't debug it.
"Debug on Kubernetes" is what I would like to use but it doesn't watch the changes and re-deploy automatically and stopping and starting the whole app (all pods) is pain because it takes 2-3 minutes (due to slow starting but never changing pods).
I was thinking of have "Run on Kubernetes" and then use Attach to debug individual pods but it would require pre-configuring the pods/containers for debug in Dockerfile. I assume if I do that, I could detach debugger and let it re-deploy watching changes and re-attach again.
I was playing with multiple skaffold yaml files - one that includes foundation only (slow starting pod) and another one just for fast-starting pod where I need to do changes but then I have to disable clean up so it's manual pod stopping for me. Also, it seems to keep stopping/starting minikube when I stop/start "Debug on Kubernetes".
I wish I could just use "Debug on Kubernetes" that watches changes and re-deploys. But watch is not supported for Debug runs.
Am I missing anything? Any good ideas?
#Alex - thanks for filing the issue. Will followup further discussion on it. Glad to hear you like using cloud shell we provide same experience there that is available in VSCode. Regarding minikube stop it is intended behavior for local debugging but we can discuss more on the ticket. Sorry it doesn't let me comment inline for now.
Related
We have a microservices/ish archictecture we currently on a VM. Each of our applications are deployed as DLLs with no executable. To run them, we spawn a new instance of our activator, passing the path of the application as an argument. The process activator injects behaviors on the application via DI, such as proxies and service discovery logic.
This has the benefit that the applications and the process activator can be developed, managed and deployed independently of one another. If we have an update for the activator, we only need to deploy it and restart all applications for our changes to take effect; No need to re-deploy an application, much less to rebuild it.
As we are now developing a plan to migrate our archictecture to Kubernetes, however, we've hit a roadblock because of this design. We haven't been able to find a way to replicate this. We've thought of doing it by simply deploying the two together and setting the activator as the entrypoint; However, that would mean that anytime we update the activator, all applications' images would have to be updated as well, which completely defeats the purpose of this design.
We've also thought of deploying them as two different containers and somehow making the activator read the contents of the application container and then load its DLLs, but we don't know if it's possible for a container to read the contents of another.
In the end, is there a way to make this design work in Kubernetes?
If the design requires the following:
Inject files into the main container to change its behaviour
Then a viable choise is to use init containers. Init containers can perform operations before the main container (or containers) starts, for example they could copy some files for the main container to use.
You could have this activator as the main container and all the various apps being a different init container which contains the DLLs of that app.
When an init container starts, it copies the DLLs of that app on an ephemeral volume (aka emptyDir) to make them available to the main container. Then the activator container starts and find the DLLs at a path and can do whatever it wants with them.
This way:
If you need to update the activator, you need to update the main container image (bump its tag) and then update the definitions of all the Deployments / StatefulSets to use the new image.
If you need to update one of the apps, you need to update its single init container image (bump its tag) and then update the definition of the Deployment / StatefulSet of that particular app.
This strategy works perfectly fine (I think) if you are ok with the idea that you'll still need to define all the apps in the cluster. If you have 3 apps, A, B and C, you'll need to define 3 Deployments (or StatefulSets if the apps are stateful for some reasons) which uses the right init containers.
If the applications are mostly equal and only few things changes.. like only the DLLs to inject to the activator, you could think of using HELM to define your resources on the cluster, as it makes you able to template the resources and personalize them with very little overhead.
Some documentation:
Init Containers: https://kubernetes.io/docs/concepts/workloads/pods/init-containers/
Example of making a copy of files between Init container and Main container: https://kubernetes.io/docs/tasks/configure-pod-container/configure-pod-initialization/
HELM: https://helm.sh/docs/
Is it possible to run kubectl commands and see the run-time execution using an IDE like GoLand for example?
I would like to open 'apply.go' source code and see how the code is executed when I type: kubectl apply -f/hit Enter step-by-step.
Go does offer a debugger, Delve. But I don’t think this will be very helpful. Kubectl code is kind of hard to understand even if you already know it and kubectl apply is the single most complex thing in all of kubectl. So complex that the logic is being moved to the server side, in newer versions.
Lens is the best IDE for kubernetes that I have used upto now.
It serves everything in a plate , as there is no need to mug up the commands of kubectl,
you can make changes in any of kubernetes yaml file from lens and it will apply changes in to your cluster.
install lens for your OS: https://github.com/lensapp/lens/releases/
you can know more about lens from this link : https://github.com/lensapp/lens/
I'm getting my way through the HLF 2.0 docs and would love to discuss and try out the new features "External Builders and Launchers" and "Chaincode as an external service".
My goal is to run HLF2.0 on an K8s cluster (OpenShift). Does anyone wants to get in touch or has anyone already figured his way through?
Cheers from Germany
Also trying to use the ExternalBuilder. Setup core.yaml, rebuilt the containers to use it. I get an error that on "peer lifecycle chaincode install .tgz...", that the path to the scripts in core.yaml can not be found.
I've added volume bind commands in the peer-base.yaml, and in docker-compose-cli.yaml, and am using the first-network setup. Dropped out the part of the byfn.sh that would connect to the cli container, so that I do that part manually, do the create, join, update anchors successfully, and then try to do the install and fail. However, on the install, I'm failing on the /bin/detect, because it can't find that file to fork/exec it. To get that far, peer was able to read my external configuration, and read the core.yaml file. At the moment, trying the "mode: dev" in the core.yaml which seems to indicate that the scripts and the chaincode will be run "locally", which I think means it should run in the cli container. Otherwise, tried to walk the code to see how the docker containers are being created dynamically, and from what image, but haven't been able to nail that down yet.
I am using JBoss Developer studio 10.1.0.GA.
I have a fuse integration project. In my JMX Navigator there are so many unused maven[id] formed. How can they be removed/deleted?
Please refer the image.
Wow, how did that happen? I guess you ran a Camel context locally several times? Did you stop the process in DevStudio console view? That should usually make those processes disappear. In your case there might be several running processes in the console view so stop and close one by one.
Alternatively you could terminate them manually either via the Task Manager (Windows) or by invoking "kill " (Linux).
I would really love to hear what you did to get into that state.
I am using following command to deploy code to my AEM instance "mvn clean install -Daem.host=localhost -Daem.port=1202 -Dmaven.test.skip=true
"
After deployment pages are taking too long to load at least 7 mins.
I found No errors/Exceptions in error log.
There could be couple of factors causing this slowness -
Amount of memory allocated to AEM instance, default setting is - CQ_JVM_OPTS='-server -Xmx1024m -XX:MaxPermSize=256M -Djava.awt.headless=true' which is actually not sufficient for optimal performance. I have been using double of this configurations and sometimes even more.
When you deploy your package with code, the bundles are processed and services are registered. Depending on number of services/components being registered the time can go up. Sometimes there are hooks within code that cause few system level bundles to cycle as well, if that happens it would actually cause all the other bundles dependent on system bundle to cycle and registering the services again.
your code deployment could be triggering some workflow that either consumes lot of resources or is causing delayed activation on your bundle. The first scenario could happen if your deployment has something like images which when deployed causes OOTB image workflow to trigger (there could be other based on your code). Second scenario could be that you have bundle activator either waiting for another bundle which gets deployed later (and/or stays installed and not active) or you are building some sort of caching that waits for pages to be deployed and processed. There are countless such scenarios that can cause this issue.
What you could do is check the status of the bundles in /system/console/bundles pre and post deployment you can identify bundle related issues there. Another thing you could try is to do selective deployment of the code to figure out what module is causing issue that then dive deeper in to that module.
Also look at recent request logs to identify the flow of page load to see if there are services, filters etc in picture that are causing delays.
Let me know if any of this approach helps you identify the root cause and in case you need further help, will be here to assist.