I would integrate the schema management into the application itself (or along with it).
Any change to the schema should be committed along the application code (and hence tagged also).
There's already a bunch of possibilities listed in this question: What practices or tools enable Continuous Deployment of Databases
With this kind of tools, using an in ...
So I managed to keep the same structure roughly, and managed to separate how the machines are generated, however still is a bit fuzzy and can probably be improved to be more efficient!
- name: Apply common configuration to all nodes
- name: Configure and deploy test node 1
There are, as always, a few ways to solve this.
You can use a central source to keep secrets that each server reads from ala Hashicorp Vault. While popular this is not my preferred approach as its rather complex. There are quite a few key value stores that can provide similar functionality such as AWS Parameter Store.
You can manually put data in these ...
I don't really understand this one:
However, this seems clunky, as I have to create the logic to read this
file in every script that is made.
You can source all variables from a bash file in one line (source file-name.sh). If they are "exported", you can pick them up in applications in any language you like (Java, python, or whatever), ...
In our company we manage our application code within a VCS (Git) and most of the applications we work with install their core database from within the setup scripts that ship with the application.
If we would have to extend or customize an application for one of our customers which involves having to extend the database or do database customizations, then ...
I've never heard of an "Environment Manager." Release Management, on the other hand, has historically been consolidated to a single person or team.
In a DevOps model, Release Management is more of a process supported by elements from both Dev and Ops. Organizations at high levels of "DevOps maturity" don't really have a distinct Release Management event-...
A good rule of thumb is to try and avoid using one bit of logical kit (be it a single VM or a single physical host) for more than one thing.
If a physical server is going to be a VM host then that's all it should be. If a VM or a physical host is going to be a source code repository then that's all it should be etc. You can squeeze a bit extra out of your ...
This is a common problem in configuration management, and while I can't speak for Chef as I haven't worked with it, I can tell you how this is solved by both Puppet and SaltStack.
Firstly, this distinction becomes a little less important with interpreted languages since there isn't much difference between including this sensitive data in a configuration ...
What you're after is referred to as "Review Apps" by Gitlab and Heroku. It relies on a CI/CD system that runs pipelines on every branch, and exposes the branch name to the build (usually as an environment variable). You can then use the branch name to namespace the resources created by your Infrastructure as Code.
You have mentioned Docker so I will use ...
If the different CDNs are hosted at different IP addresses one possibility might be to configure the local hosts table for the machines in a certain environment in such way as to overwrite the DNS resolution for the CDNs which shouldn't be accessible and pointing them to either:
a non-existent address, causing connection timeout failures if the invalid CDNs ...
How big is the app? How much usage will it get in staging?
If you spin it up on a t2.micro, the extra cost will be negligible, especially if you use auto-shutdown or Terraform to only have the box running when you need it.
It's critical to have separate environments for staging and production.
Finally, consider dockerizing your app if you can. Much more ...
You can approach this case with multiple ways.
For example you can set an auto-shutdown for 20:00 pm and auto-start for 8:00 am.
Use Terraform to create your environment and, after deployment/testings, you can easily destroy it, saving your costs.
And many other ways.
I commented on paths that you can follow, so you should choose one that brings you ...
It's really up to your personal preference, but for minikube you can certainly follow the same standards that you would for production.
If your production environment will use some sort of volume mount for your application code, then follow that same workflow for local dev and just have a pod running that mounts to your local code.
If your production ...
Based on my experience I'd suggest following scenario:
First you should make your apps deployment process similar for all environments, so same tool and set of files will be responsible for this part. And only difference should goes to parameters.
And second it's always a good practice to have kubernetes cluster per stage. Very common situation when your ...
You can use Terraform for azure to handle the dynamic creation of azure resources in the release pipeline in Azure DevOps. Terraform maintains a state file for all the created resources after a run.
If the script is run multiple times, it ignores already created resources unless there are any properties updated and created new resources.
FYI, follow below ...
The best way is of course (like Zeitounator comments) to use a inventory var. Either you use the version number in the docker-compose task as a variable or you create a Jinja2 template docker-compose.yml.j2 and use the variable there. That's what I do.
If it's within scope, I would use Packer to build the artifacts.
Write a Packer template using the builders that you want:
Vagrant builder for the Vagrant image
Docker builder for the Docker image.
Use the same Ansible playbook as you already have to provision each of the builders.
Note that you need to make sure that the Ansible playbook will work in ...
The best practice is to separate production and staging(testing) inventory. See Staging vs Production.
This way you pick with -i what you are targeting.
To make it more robust you might want to clone a separate structure for production and restrict access to it. Pull from staging before deploying to production.
In detail, this would mean to 1) put the ...
This is a general issue with react apps that is independent of what CI/CD stack you use that is discussed at https://stackoverflow.com/questions/49975735/rendering-an-environment-variable-to-the-browser-in-a-react-js-redux-production
With the Azure family of CI/CD products it is expected you create a release artefact then release that same artefact into ...
- include: Debian.yml
when: ansible_os_family == 'Debian'
put everything that is required on debian like apt in Debian.yml and yum in Centos.yml.
In summary, it is possible to let all OS types use the same role if the OS specific things are put in separate files.
This is a more comprehensive example https:/...
As I see it, the basic problem you have is that you aren't looking at the Total Cost of Ownership (TCO). While you may eventually save on the hardware costs, this is costing you in man-hours - either yours or your employees - a cost which you also pay out of pocket until you begin generating revenue.
The reason for this is this: Instead of using a ready to ...
we do this with .conf files and loading them via compose
they can also be used with
docker run --env-file /path/to/our.conf ourcontainer:version
In some cases we use the variables defined in our conf files directly, meaning the code we are running reads them direct, in others we need to modify other files on a per environment ...
I see three way to handle this need.
The software declare its dependencies and is released with each dependency at the correct version independently of others. This may create problems if two version of the same dependency are not compatible for database access for example and need a system above to ensure only compatibles version are deployed toward an ...