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
Related
Building a Spring based project deployed in kubernetes using Spring Cloud Kubernetes library with Kubernetes. The build is using maven and GIT CI/CD. Exploring the build process to package environment specific files and the runtime to pick up env specific files during execution. In traditional deployment, used to use maven profiles to build env specific libraries and configurations. Now spring has profile and maven has its profile. Besides, some of the designs includes files/configurations for all env included in the build and only a activated profile will use the correct configuration. Is it advisable to include all configurations in the package?
Is there a best approach on how these two work in handling env specific files or any other optimized approach to handle this?
I'm afraid that:
In traditional deployment, used to use maven profiles to build env specific libraries and configurations
was never a case for maven profiles, if you take a look at official guide you may find following:
Apache Maven goes to great lengths to ensure that builds are portable. Among other things, this means allowing build configuration inside the POM, avoiding all filesystem references (in inheritance, dependencies, and other places), and leaning much more heavily on the local repository to store the metadata needed to make this possible.
However, sometimes portability is not entirely possible. Under certain conditions, plugins may need to be configured with local filesystem paths. Under other circumstances, a slightly different dependency set will be required, and the project's artifact name may need to be adjusted slightly. And at still other times, you may even need to include a whole plugin in the build lifecycle depending on the detected build environment.
To address these circumstances, Maven supports build profiles.
So, maven profiles was designed to support codebase portability across build environments, but not to build artifacts for particular environment.
"Traditional" way to inject environment-specific settings into j2ee-application was to setup those settings via JNDI, i.e. j2ee-container was providing a configuration via JNDI and our application was consuming that configuration via JNDI. In case of spring/k8s/etc the main idea should remain the same: application knows how to retrieve configuration (system properties, environment variables, configuration server, service discovery, etc) and environment provides that configuration.
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.
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?
I have a Jenkins cluster that is shared by several teams, that I can configure build jobs on, However i can't easily make changes to the Jenkins configuration itself.
There is a central "nexus pro" maven repository manager but each team / group in this very large multinational has their own repo, publishing to the repos requires username / password combination.
This means that I have to configure the Jenkins server with a maven settings.xml that is unique to the team I am working with without messing up the maven configuration of the other users of the Jenkins cluster.
Git is the source control repository.
On a shared Jenkins cluster how do I configure a maven settings.xml that is unique to a a group of build jobs or to a single job? What are the best practices for handling this type of situation?
I would recommend using the configuration file plugin, provides a UI to edit one or more Maven settings files.
These settings files can be passed into your Maven build using the "-s" option.
You can specify for each job in the Maven Advanced Options part a specific seetings.xml path
We manage all our build nodes using Puppet. It gives you greater control than just settings.xml. Highly recommended
Puppet is IT automation software that helps system administrators manage infrastructure throughout its lifecycle, from provisioning and configuration to patch management and compliance. Using Puppet, you can easily automate repetitive tasks, quickly deploy critical applications, and proactively manage change, scaling from 10s of servers to 1000s, on-premise or in the cloud.
If your company is using Nexus Pro (as you've already mentioned), then your unique Maven settings.xml can be stored there, and retrieved at build time using the nexus-maven-plugin as described here: http://books.sonatype.com/nexus-book/reference/maven-settings.html
Combined with token-based access (again, Nexus Pro does this), you do not need to store passwords insecurely in the settings.xml (see https://books.sonatype.com/nexus-book/reference/usertoken.html)
I faced the similar issue when building the project with jenkins as ojdbc jar is not available in maven central repository.
It worked when I placed the ojdbc jar in WEB-INF/lib folder and removed the maven dependency in pom.xml.
A good way to automate the provisioning of maven executors with specific configuration, is using ElasticBox Jenkins plugin.
You only need to create a box for the Maven slave, that define all the customization variables and files to be used by it and choose your preferred cloud provider for deploying it.
ElasticBox gives you also the flexibility to create new slaves only when needed and automatically destroy them after an specified retention time.
Here is how-to connect your Jenkins with ElasticBox:
https://elasticbox.com/documentation/integrate-with-jenkins/jenkins-elasticbox-setup/#jenkins-configure-plugin
Here is how to automate creation of Jenkins slaves with ElasticBox:
https://elasticbox.com/documentation/integrate-with-jenkins/jenkins-elasticbox-slaves/
There is a blog post about how easily build and deploy from GitHub pull requests with ElasticBox Jenkins plugin:
https://elasticbox.com/blog/github-pull-requests-jenkinsplugin/
I have a Web Application that is environment independent so it's a single war that can be deployed to multiple environments.
I have created multiple Tomcat Servers (i.e. Devel, QA, Production) and defined them in in the NetBeans server configuration.
I'm able to run the war against each of the environments fine by manually changing the project properties but I would like to be able to set what server to connect to from within Maven and either add custom Debug/Run actions or by using maven profiles.
I've tried setting:
<netbeans.deployment.server.id>tomcat70:home=C:\Apache\Tomcat\7.0.34,base=C:\Apache\Tomcat\Devel</netbeans.deployment.server.id>
but that didn't work for me.
Does anyone know if this can be done?
Thanks,
Rob
The proper way to do this is to setup separate profiles in your pom and then have the property set in each of those profiles.