I'm trying to automate the process of deploying code using github and jenkins job to deploy my Springboot Application on AWS .
I want to know where should I place the application.properties file in case I m deploying a war file on Tomcat and don't want this file to be pushed onto github as it may contain some database credentials , not to be exposed.
Should I put separate application-prod.properties file in Tomcat (AWS) so that my war file will be independent of these properties ?
See my answer here.
In a nutshell, you externalise the properties and then pass one or more profiles that will activate one or more Spring Configuration classes. Each Configuration class will load one or more property file. In your case, if you only have one environment, you can just create a configuration file for one profile.
Then, on your AWS instance, you will deploy the configuration file separately. At runtime, you will need to pass to your Spring Boot application the active profile(s). You can do this by passing the VM argument: -Dspring.profiles.active=[your-profile]
I'm completing the final lectures on an online course that shows how to create from scratch a Spring Boot website with Thymeleaf, Spring Security, Email and Data JPA, how to process credit card payments with Stripe and how to deploy to AWS. You can register your interest here.
how about using spring-cloud-starter-config instead of local properties ?
If using spring-cloud-start-config, all configurations should be loaded from your config-center instead of reading them locally.
Even if you have multiple different environments, spring-cloud-starter-config could handle it with different profiles.
What's more, spring-cloud-starter-config could use local environment variables too.
By the way, the only local resource could be bootstrap.yml if you are using spring-cloud-starter-config.
Wish I can help you!
Related
I am deploying a Django application using the following steps:
Push updates to GIT
Log into AWS
Pull updates from GIT
The issue I am having is my settings production.py file. I have it in my .gitignore so it does not get uploaded to GITHUB due to security. This, of course, means it is not available when I PULL updates onto my server.
What is a good approach for making this file available to my app when it is on the server without having to upload it to GITHUB where it is exposed?
It is definitely a good idea not to check secrets into your repository. However, there's nothing wrong with checking in configuration that is not secret if it's an intrinsic part of your application.
In large scale deployments, typically one sets configuration using a tool for that purpose like Puppet, so that all the pieces that need to be aware of a particular application's configuration can be generated from one source. Similarly, secrets are usually handled using a secret store like Vault and injected into the environment when the process starts.
If you're just running a single server, it's probably just fine to adjust your configuration or application to read secrets from the environment (or possibly a separate file) and set those values on the server. You can then include other configuration settings (secrets excluded) as a file in the repository. If, in the future, you need more flexibility, you can pick up other tools in the future.
My group is using Jenkins to build and deploy a Spring Boot application to AWS (Elastic Beanstalk).
For development I was selecting the desired profile for the environment I was in (DEV, QA) by setting the spring.profiles.active property in application.properties.
But dev-ops would like to set the property externally. Since the app is being deployed to a SpotInst managed EC2, I have no control over the environment.
I've been doing a lot of searching, but haven't as yet come across anything that fits this situation.
I'm using Gradle for building. The build generates a WAR file and is deployed to Tomcat.
Is there anyway to accomplish this with some sort of parameter substitution?
Thanks.
Our devOps person discovered that we can set environment properties through AWS Beanstalk. By going to Configuration on the beanstalk instance and clicking on the Modify button under Software, scroll down and there is a section for environment variables. He put in spring.profiles.active=qa and that took care of it.
Since we have one beanstalk for each separate environment, it only has to be set once for each.
I am not sure if this will fit into your devOps process but there is very easy and clean way to achieve this.
Configure your application.yaml file like below:
spring:
profiles:
active: ${SPRING_PROFILE:"dev"}
And while starting the application pass this parameter SPRING_PROFILE as command line argument. Note that dev is default value which will be used if the program doesn't find any matching command line argument or environment variable.
You can set the default value to the one you want to use for devOps while for all other purpose where you can control you can pass as argument.
I am new to VSTS build and deploy and I am struggling with it.
I have a solution that contains a Web Core API and a ASP.Net web project.
I have done my build and now I want to deploy the build to an on premise web server.
When I look at my artifacts, everything looks OK;
So when I set up a deploy definition I start with an empty environment and I add a task. It looks to me that given I want to move the artifacts to an on premise web server I should be using the Windows Machine File Copy task. But when I do I find that I do not have access to the drop folder. How do I fix this (and have I selected the correct task?).
You're using the hosted agent. The hosted agent can't deploy to an on-prem server -- it has no network route.
You can either use Deployment Groups (the agent is installed on your target machine and talks directly to VSTS), or you can install your own on-prem build/release server, then push the bits to the target machine using the Windows Machine File Copy task.
We are trying to deploy a web job via octopus. We have different eventhub keys saved in the variables and we expect the webjob to pick up the right key depending on the environment that it is being deployed to. Has one one done this before? Any advice on settings up configurations in octopus?
<========== UPDATE ===========>
We were being careless and didn't quite set our octopus process to transform the Configuration Variables. You should be able to do so by clicking 'configure variables' in the process step.
I don't think it being deployed via Octopus is all that relevant here. Generally, a .NET WebJob is able to access Azure App Setting using standard configuration API.
If that is not working for you, please update your question to clarify what you tries, and specifically what didn't work.
We have a "mavenized" project with several containers (wso2esb, wso2dss, tomcat) and many components to deploy to them.
We are trying to find a way to deploy the datasource configuration for all our DSS services but I notice it is stored in its own DB (H2).
Do you know if there is any way to declare something like a XML file in order to create the datasource in the DSS in an automated way?
I tried to see the documentation but did not find anything useful for automatic deployment (meaning without using the admin pages).
Yeah, you can use the Carbon data source configuration file datasources.properties, to provide this information. This file should be located at $SERVER_ROOT/repository/conf.
A sample for this configuration file can be found in BPS sources.
After the data sources are defined using this, you can use them using the data source type "carbon data source" from data services.
You can easily deploy artifacts with the hot deployment functionality in WSO2 Servers by simply copying them to a specific directory in the server.
For Data Services Server you can copy the dbs files (in your case with the help of Maven) to $WSO2DSS_HOME/repository/deployment/server/dataservices dirctory. Similarly for BPELs its $WSO2BPS_HOME/repository/deployment/server/bpel
For CAR files created with carbon studio, its $WSO2CARBON_HOME/repository/deployment/server/carbonapps.
For ESB configs, its $WSO2ESB_HOME/repository/deployment/server/synapse-configs.