If I update config vars changes are not populated to website. I need to redeploy the application to see changes.
The interesting part is it worked without redeploying before and we have not changed anything since that time.
Here's example of updating from cmd
Are there options that define that behavior?
Config variable changes lead to dyno restarts, always.
Only thing I can think of is preboot, which can lead to some minutes of time between the config-change and the change actually being visible in the web-application.
Related
I have a dockerised spring-boot based application and i wanted to update some of the values in application.properties. And this seems can be achieved in 3 ways.
Update the application.properties file, rebuild the image.
Add --spring.config.location= to the ENTRYPOINT, update the prop file, rebuild the image.
Use volume mount, mention the prop file location, update the prop, rebuild the image.
Using Spring Profiles and pass the profile info before running the container. And even in this approach update the profile specific prop file, rebuild the image.
As we can see all the approaches involve rebuilding images. Is there a way to make changes to application.properties without rebuilding the image? What is the preferred approach in prod scenarios?
Thanks!
Yes, there is one more way to inject properties using environment variables.
As per spring property resolution order, environmental variables take precedence over property files.
For example, say you want to update the spring.datasource.username, you can set it via environment variable as SPRING_DATASOURCE_USERNAME. Basically, replacing . with _. By nature, environment variables are not case sensitive but by convention, we put them in upper case.
This variable can be passed when you will be creating container from your image as suggested in this answer.
I would recommend using environment variables, as #YogeshBadke suggests in their answer.
Your option of using a volume is also a good option. Host files mentioned using docker run -v replace files in the image when the container is started, and this does not require an image rebuild. For example
docker run -v $PWD/application.properties.prod:/app/application.properties ...
As a general rule you should not need to rebuild your image to run it in a different environment, and you should avoid mentioning environment-specific hostnames or similar settings anywhere in what gets built into your image. I would not recommend having separate "dev" vs. "prod" profiles in a Docker-hosted solution, since you'll have to rebuild the image as soon as you add a "qa" environment or anything else happens; it's better to be able to just change the deploy-time settings.
(If you happen to be deploying this in Kubernetes, my experience has been that setting individual values via environment variables is easiest, injecting an entire properties file via a ConfigMap works, and trying to embed the properties in the image simply doesn't.)
I have some code in my app that purges our cache (using Cloudflare's API) every time it starts up so that whenever a change to the website is deployed it shows up instantly for everyone instead of the old version remaining in Cloudflare's cache indefinitely.
Heroku restarts my dyno every 24 hours. This purges Cloudflare for no reason, causes a large spike in traffic, and messes with analytics.
Is there a way to detect on startup if this app restart is occurring due to an actual Heroku deploy, or just due to their daily restart?
One way I've considered is using GitHub's public API to check on startup if a commit has been pushed to master in the last hour, but that seems like a hack and there is probably a better way.
This is a classic use case for a release phase task (bold mine):
Release phase enables you to run certain tasks before a new release of your app is deployed. Release phase can be useful for tasks such as:
Sending CSS, JS, and other assets from your app’s slug to a CDN or S3 bucket
Priming or invalidating cache stores
Running database schema migrations
If a release phase task fails, the new release is not deployed, leaving your current release unaffected.
Move your "clear cache" logic to a separate script and add it to your Procfile, e.g.:
web: python some_main_command.py
release: python clear_cache.py
I gave my app access (via environment variables) to my own Heroku API. This allows it to query the API, asking when its own most recent release was. If the most recent release was more than 24 hours ago, we do not purge Cloudflare. Code is here https://github.com/ImpactDevelopment/ImpactServer/commit/db1cced1ed298b933cee87457eaa844f60974f60#diff-12a774f9437b88d4b4ebbd4e2ab726abR25
This detects anything that causes the app to be rereleased, including code changes, env variable changes, add-on changes, etc.
I'm fairly new to server administration. I have my Laravel app up and running and I want to make sure it has proper backups. I have researched some backup packages and I have settled on https://github.com/spatie/laravel-backup.
However, once the server fails, I need to know how to use the most recent backup (which will be on AWS S3) to restore the database on the rebuilt server. Are there any suggestions for guides on how to do this? I can't seem to find any unless it doesn't really require much learning and instead just a couple mySQL commands.
Thanks!
I would use replication and within Laravel i would try to switch connection to the replica database server so things can run smoothly until the problem is resolved.
Take a look at this Cross-Region Replication
A typical production environment is automatically running backups on most important things that your deployment needs in order to recover from a failure. Those parts would commonly be your database and storage folder, and configuration files.
Also when you deploy a laravel application there aren't many things that are "worth" backing up , you can choose the entire disk to be mirrored somewhere or you can schedule a backup script which run every N times and backups the things that are more important to your application.
Personally i wouldn't rely on an package from laravel to handle my backups , you can always use other backup utilities, replication and so on.
Update
Take a look at the link below:
User Guide » Amazon RDS DB Instance Lifecycle » Backing Up and Restoring
Backing Up and Restoring
You can call the API function RestoreDBInstanceFromDBSnapshot as showed on example.
But i don't think something automated exists that would auto restore or magically make everything work, you need to do a lot of security checks if something like that would even be attempted. Final word i believe a good solution manually entering or sending the request would be the most solid solution.
So, I've deployed a Java web application (myapp.war) to a Tomcat 7 server that happens to be running on Amazon EC2. I noticed that, when I do this, it overwrites a similarly-named directory called myapp when I deploy. I further realized that the app is actually being served from that myapp directory and, when I directly make a change to a file in that directory, the changes are served to the client as expected.
My question is does Tomcat do anything to this directory between redeployments? If I make a small change in a file in that directory, will it ever be overwritten before I redeploy again?
It depends.
Changes to class files will probably be ignored.
Changes to JSPs may take effect depending on if the JSP has already been accessed and if the JSP Servlet is configured to check for changes.
Changes to static files will probably take effect but may be delayed by the effects of the static file cache. Normally that delay is only a few seconds but it can be configured to be longer.
Editing web.xml will probably trigger a reload (again this can be disabled with config)
Editing contex.xml will probably trigger a redeploy.
A reload pauses the app, re-reads web.xml and unpauses the app so the user might see a short pause but no 404s. A redploy completely removes the old app and creates a new one. A user may see a 404 in they try accessing it at the wrong time.
As soon as a new WAR file is deployed, all local changes will be lost.
I recently implemented Capistrano for the first time with a new cloud production environment. When I run cap deploy, everything seems to work fine. I can visit my live application in the browser, but my static files seem to load very slowly (like 5.0-12.0s).
See answer for clarity on config.assets.compile.
Static files load slowly because they possibly are not static, but are being served by Sprockets.
Check in production.rb and see if config.assets.compile = true or it is not set. That would mean that Sprockets is doing the work. You would also see far-future headers being used.
Have a look in /home/my_user/my_app/current/public and see if assets exists; I suspect it does not.
That means that mkdir -p is not working. The most likely cause is that the deploy user does not have sufficient permissions to create the directory.
Fix that, and also check (if this is an upgraded app from 3.0 or before) that your config setting match those in the last section of the pipeline guide.