As per Martin Flowers' definition of Blue-Green deployment
The blue-green deployment approach does this by ensuring you have two production environments, as identical as possible. At any time one of them, let's say blue for the example, is live. As you prepare a new release of your software you do your final stage of testing in the green environment. Once ...
I don't think the proposed plan here makes much sense. Tools like Ansible are free and designed to do this with good, central management and logging.
Put code in BitBucket.
Make a Jenkins server (open source / free / low on resources
/ well documented and easy to use).
Make BitBucket call Jenkins with a hook on change.
Or, if you feel like it, Jenkins ...
Helm isn't made to be used this way. If you'd prefer to use a static deployment, you're better off using a plain Kubernetes manifest. Then, people changing the image field won't break your release.
You can easily convert it to one simply by running helm get manifest command
Helm is used to manage release versions. I.e. every new release (and a docker ...
You're basically describing GitOps. Here's how I've followed that for a containerized microservices build and deploy pipeline:
Each service repo includes it's own Dockerfile, Kubernetes manifests, and anything else needed to locally build and test the project. The base image for the Dockerfile will likely be managed from another repo but built and hosted by ...
You're bringing up a big pain point - and there are 2 camps here, people who do GitFlow and people who prefer other approaches (with TBD being most popular).
Personally, TBD with release branches is something I would always prefer, but you can find lots of other people who would tell you GitFlow is better - so you'd have to decide for yourself.
In your ...
As promised, here is a solution using haproxy with sticky cookies. Note, that this approach requires support on the application side (as only your application layer may know once transactions are completed).
To achieve this, first - start with haproxy configuration of the following kind:
Very good question; I'm interested to see what comes up here.
In terms of cost, obviously each company and team is different. Ideally, everyone should be resource and cost conscious... but most people really don't seem to penny pinch by heavily monitoring and tuning their workloads (probably as that takes a certain skill level and tool set).
My Thoughts ...
the idea is for each team member to have his/her own environment assigned, but deploy using a shared parametrized pipeline
You could use definitions for the steps for each environment.
- step: deploy to staging1
- echo "Staging 1"
- step: deploy to staging2
- echo "Staging 2"
YAML anchors are supported, but only for the same YAML file. You can't create the anchor (&) on a deployment file and reference (*) the value on another one.
If you want to share ENVs values across multiple Deployments, you can create a ConfigMap with the ENVs and use the envFrom spec. Example:
ansible-pull would work well for this, though it makes the assumption that your clients are using ansible. That's not an assumption I would be comfortable making in your shoes.
At this point it would appear to me that developing our own script to further automate the process would be a better solution
I agree with that. Since you already have a script to ...
It looks like you are configuring two services, mysql and mysql-nodeport to use the same port. Without information to indicate otherwise im assuming this is a 1 node setup with rasbian. I personally dont have raspbian installed to test, but try something like this: