I see there are many Github pages for gradle kubernetes plugin like
https://github.com/bmuschko/gradle-kubernetes-plugin
https://github.com/kolleroot/gradle-kubernetes-plugin
https://github.com/qaware/gradle-cloud-deployer
None of these having any concrete example how to connect to kubernetes from gradle and create a new deployment and service I tried all about git link in gradle but no luck...
Since I also faced a lack of plugins that deal with Kubernetes I started working on a Gradle plugin to make deploying resources to a Kubernetes cluster easier: https://github.com/kuberig-io/kuberig.
In the user manual you will find details about how to connect to a kubernetes cluster here:
https://kuberig-io.github.io/kuberig/#/initializing-an-environment
It also includes an example of how to define a deployment here: https://kuberig-io.github.io/kuberig/#/defining-a-deployment
And a service here:
https://kuberig-io.github.io/kuberig/#/defining-a-service
It may also be useful to go through the quickstart first https://kuberig-io.github.io/kuberig/#/quick-start.
Hope it can be of use to you.
Related
I am working in a Java Springboot microservice-based complex application that comprises 30 services.
All are containerized and from ECR, services are deployed inside the Kubernetes namespace in AWS.
Every time, the namespace is purged and all services are re-deployed.
How can I update only one service inside a namespaceā¦is it possible to do that kind of deployment.
Can someone please Any sample configurations using helm or any useful links
How can I update only one service inside a namespaceā¦is it possible to do that kind of deployment.
If you are executing helm upgrade it should only update the resources which are updated.
you need to understand how does Helm packs the resources, helm is using Kustomization so if you are updating Secrets, ConfigMap etc it will generate new names for those resources.
As a side effect, it will "change" the Deployment and the results will be a "full" deploy of all the resources
I've an ECS cluster running Fargate instances with Springboot apps & want to enable tracing with least number of code changes. There're the two approaches I started looking at:
Use AWS-Xray : Steps -> Add dependencies, add aWSXRayServletFilter, run X-Ray daemon in a separate container.
Use Spring Cloud Sleuth : Steps -> Add dependency & property, integrate with X-Ray
So the second approach saves you number of steps in modifying your code, the issues is I couldn't find any good doc to integrate Spring Cloud Sleuth with X-Ray, can anyone point me to correct direction?
I tried reading number of docs including: https://cloud.spring.io/spring-cloud-sleuth/spring-cloud-sleuth.html
I came across this when looking for a solution for option two. AFAIK, you still have to use the X-Ray daemon. I had to look across multiple GitHub repos and issues to solve the problem so am providing the solution here.
I used Gradle for my solution but this can be easily translated to Maven as well.
Add the BOM for spring cloud
dependencyManagement {
imports {
mavenBom("org.springframework.cloud:spring-cloud-dependencies:2021.0.3")
}
}
Add the following dependencies to the project.
implementation 'org.springframework.cloud:spring-cloud-starter-sleuth'
implementation 'org.springframework.cloud:spring-cloud-sleuth-zipkin'
implementation 'io.zipkin.aws:zipkin-reporter-xray-udp:0.23.4'
Then Add configuration to define the Bean which is used for reporting to the X-Ray daemon.
#Configuration
public class TracingConfiguration {
#Bean(ZipkinAutoConfiguration.REPORTER_BEAN_NAME)
Reporter<Span> reporter() {
return XRayUDPReporter.create();
}
}
Define the propagation type as aws for Sleuth as per the documentation.
spring.sleuth.propagation.type=aws
I haven't tried it yet, but from the documentation you can combine the following
An amazon/aws-xray-daemon
zipkin-aws with the experimental X-Ray Storage. They have a Docker image for zipkin-aws. You need to point it to the XRay daemon. This will be running as a Zipkin server listening on port 9411.
Then you use Spring Cloud Sleuth's instrumentation and AsyncZipkinSender.
By doing this approach, you can decouple yourself from AWS as long as you have a different zipkin server.
currently AWS X-Ray SDK doesn't have integration with Spring Cloud Sleuth. In order to using AWS X-Ray, the first approach would be the best way to do it.
I have a multi-modules vertx application deployed on OpenShift. For integration testing purposes, I would like to deploy a database container with pre-defined data, and destroy it when the test is finished.
How can I achieve this ?
My application uses junit and maven fabric8 plugin to deploy containers in Openshift.
This is something that could be done relatively easy using arquillian-cube, which does support Kubernetes and Openshift.
What arquillian-cube can do for you, is to (optionally) create an ephemeral project, deploy everything you need for your test and once everything is up and running, then start your tests. In the end it can also do the cleaning up for you.
It is quite flexible so according to your needs and requirements it can work with either ephemeral or fixed projects. And also there are pletny of configuration options when it comes to cleaning up.
Last but not least, it does play quite nicely with the fabric8 maven plugin.
https://github.com/arquillian/arquillian-cube/blob/master/docs/kubernetes.adoc
Does the maven-fabric8-plugin have the ability to support multiple profiles for different Kubernetes clusters?
I have no problem building the resources and deploying to a local minikube instance and my yaml files are under src/main/fabric8.
However I would like to be able to specify different profiles such as
src/main/fabric8/local for local deployment on minikube
src/main/fabric8/dev to deploy on the development cluster
What are the recommended approaches to achieve that?
The problem had an easy answer. I ended up populating the profiles with the src/main/fabric8 directory and then in my maven build I specify the profile using the -Dfabric.resourceDir flag
This question is about running a Kubernetes deployment on Azure and we are completely new to Kubernetes. We have a new microservice called xde-deployer that we use to deploy projects onto other microservices. The xde-deployer builds projects using Maven and therefore needs a working Maven configuration. Normally this is provided in the user's settings.xml. In this case we are running it in a docker container, so xde-deployer will look for it in /root/.m2/settings.xml.
Normally when we deploy the docker container, we use a volume to pass the settings.xml which is located on the host. On Kubernetes of course this is not so straightforward. As the answers to this question state one could add the file later, or use a configMap. Both answers are a bit too vague for our purposes though. Is there really no way to do this from the deployment? I cannot imagine we are the only ones who need to pass Maven settings to jobs running on Kubernetes. How are others solving this problem? My main problem after reading the documentation is still: how do I get a file into the Kubernetes cluster at all when I am on Azure? Is there a kind of persistent volume or parameters store that can be easily shared by the pods?