Your browser does not seem to support JavaScript. As a result, your viewing experience will be diminished, and you may not be able to execute some actions.

Please download a browser that supports JavaScript, or enable it if it's disabled (i.e. NoScript).

Does `helm upgrade` use rolling restarts for `deployments`, yes/no? if not then what is the default?

G
guilherme last edited by
I ask because:
- I want to know what is the default helm upgrade behavior
- I might need to change the default helm upgrade behavior
Does helm upgrade use rolling restarts for deployments? If not then what is the default?

If helm upgrade is not the thing that controls the behavior for deployments, please say what does. (I suspect the deployment controls the behavior of what happens during a helm upgrade but I am not sure so I am asking.)
Reply Quote 0
1 Reply Last reply
A
Avante last edited by

Helm upgrade is making revisions to the deployment which means, you can roll back to the last deployment. regarding the restart of current pods, it will happen based on your definition of Deployment.spec.strategy.rollingUpdate will recreate the pods!
Reply Quote 0
1 Reply Last reply

2
Posts

0
Views

Suggested Topics

E

Validate Quality Cobol code - Jenkins, Sonarqube/SonarLint and Rational/Topaz?
Continuous Integration and Delivery (CI, CD) • jenkins continuous integration sonarqube • • emerson

2

0
Votes

2
Posts

1
Views

F

The next step is to create a proof of concept. Setup cobol code repository Create example cobol code to test jenkins/sonarqube features Create cobol unit-tests Setup Jenkins Create job to pull cobol code Run any tests and generate code-coverage Push data to SonarQube Analyze results Manual: Analyze trends and set targets Automated: SonarQube can give feedback/alerts I think the best is to just start trying and see what you run into, this could lead to better less broad questions. Try to setup a (automated) flow / process that uses these tools and see if they give you value.
T

Tool preferences for rapidly spinning up and spinning down k8s clusters
Continuous Integration and Delivery (CI, CD) • kubernetes testing ansible chef puppet • • terrea

2

0
Votes

2
Posts

1
Views

O

You could try this: https://github.com/heptio/aws-quickstart Their CTO uses it to spin up K8S clusters for his weekly youtube live stream called TGIK, in order to showcase whatever he wants to talk about. I myself use GKE so I do not need it.
M

Kubernetes create multiple jobs based on template and list
Continuous Integration and Delivery (CI, CD) • kubernetes automation yaml • • magpie

2

0
Votes

2
Posts

1
Views

K

Have you checked the documentation for cron-jobs? You can use the run command. $ kubectl run hello --schedule="*/1 * * * *" --restart=OnFailure --image=busybox -- /bin/sh -c "date; echo Hello from the Kubernetes cluster" cronjob "hello" created This way you can loop through your customers in a bash script to deploy your containers. Not knowing the big picture its hard to answer completely, but I also think ansible templates would work for this. You could turn your above config file into a jinja2 template. You could pass your customers in as a JSON dict and use with_items to loop through them or treat your customers as an inventory. This would give you an easy way to deal with certain "snowflake" customers. EDIT: as far as doing this with Vanilla Kubernetes, I don't think it's possible. You could add your own custom controller and extend the kubernetes API. This would allow you to creat an API object that defines a customer, and then have a custom controller pick that up and create your cron job. Check out https://github.com/coreos/prometheus-operator as they have implemented such a solution to allow multiple teams to run there own Prometheus solution on the same cluster.
B

How to set up WordPress CI/CD pipeline
Continuous Integration and Delivery (CI, CD) • wordpress pipeline • • Burma

2

0
Votes

2
Posts

1
Views

A

It has been a while since I have run a few Wordpress based sites. The database stores some of the content of the site. The file system stores media that is uploaded into the site. More significantly Wordpress is a Content Management System. The intention is that your site users can add content and media to the live site. When someone uses the WYSIWYG editor to add or edit the content you will find that the sites domain name leaks into the database. So if you move the Staging database into Live you would get links appearing on the Live that that point back to the Staging site. I quick bit of research to see if things have improved since I last used it leads to this article on putting Wordpress into git. Please read the first article in that series that explains the challenges. You will need to understand a little of how Wordpress works to understand the recommendations I make below. That article talks about turning off automatic updates so that you have to manually security path. I am pretty sure that I remember that updates can write things into the database. I would be very worried about turning off updates as there are a huge amount of attacks against Wordpress as it is so widely deployed. You really should avoid deploying many third party plugins as they might not get security patches in time. This isn't a theoretical problem I had quite a time dealing with Wordpress being used as a spam relay. Yet even if you follow that article you won't have solved the database migrations issue. My recommendation is that you take a step back and try to figure out what problems you are trying to solve and how to adapt the tools and process: What is the developer developing? A custom Theme and/or Plugin? If so then this article covers that. Put the Theme/Plugin into its own repo. Who actually writes the site content or uploads media? The general public or members of staff? If it is staff then maybe they need minimal training in a Test environment and can happily edit Live after that. Given that Wordpress does not let you aim for perfection due to the way that it is built, yet it is hugely successful, carefully pick which of the following you are aiming to optimise: A Specific Service Level Agreement Meantime to recovery Mean time between failures Reducing the commercial impact of errors Something else? There are quite a few other specifics that may affect what set of compromises might work best for your situation. Based on my experiences without actual knowledge of your specifics: Give up the idea of promoting changes through Dev, Staging and Live. I would simply have a Test site and a Live site. I would periodically refresh the Test site from the Live site. To do this I would dump out the entire Live database a run a sed -i over it to replace every instance of "www.mysite.com" with "test.mysite.com". Give up on using Docker as the software distribution mechanism for the actual site. I would use Docker to supply the PHP+Apache runtime and mount a volume that contained the actual site php+content. This because the disk is a combination of the code and the content of the site so you need to be able to backup and restore it independently of changing the Docker image. Try "git checkout vX.Y" to update the live site in a persistent volume mounted into your generic PHP+Apache docker image. I would investigate the ideas in this series of articles. Automate the backup of the media content volume every night and keep as many backups as you can. This is why it needs to be a volume mounted into Docker. Automate the backup of the database every night and keep as many as you can. Automate the restore of the site as a script that restores the database to the last midnight backup then restores the last nightly snapshot of the media content folder. Avoid any party plugins that are not commercially supported. They likely won't work at the next major upgrade of Wordpress and will pin you onto a version that will become obsolete. Then they workflow that I would go for would be the to add "experimental features" into the Test site before applying them to the Live site. This would be based on git checkouts in the best case. Yet I would also consider doing Wordpress security updates via the CLI. Those can update the database and the state on disk underneith Docker hence I do not recommend you try to mange the state of your site as a Docker image. You then have to worry about the Test site drifting away form the Live site. So I would on a periodic base (at least monthly) overwrite the Test site with the Live site. This would involve: Backing up the Lite sites media content on the persistent volume and restoring it over the Test sites media content on its persistent volume. Backing up the Lite sites database, doing a sed -i to rewrite any content links pointing at the Live to point at the Test site. Then restoring it over the Test database. A key part of this approach is that you would be running your Live site like every other Wordpress site in the world. You don't do "brain surgery" on the Live site. You do frequently do "brain surgery" on the Test site. If the brain surgery goes wrong it's annoying and painful to fix but it is only the Test site that needs some new step to bring it into sync with Live. It is likely that this only happens when you move to a new Wordpress version. If you try a custom approach of moving change into a Live site they might break at a future Wordpress release and leave you with a multiple-day outage in Live. I completely recognise that the approach outlined above isn't at all how "normal" software is developed. Yet it is the approach that I have scripted in the past. Even if you did the standard dev/test/live approach you do not guarantee 100% perfection and 0 bugs but you might have a longer mean time between failures. If you accept that perfection isn't possible then what you want is very fast rollback to reduce the impact of bugs. You do this by focusing on reducing the meantime to recovery to the speed of a restore script and the time taken to get permission/agreement to run it. Being able to rehearse things in a Test environment should mostly avoid a total outage on the live site. Being able to do a fully automated restore can then bring you back to a good state at the loss of some recent edits to the site. That is normally completely acceptable compared to having an extended outage. Consider this scenario: Staff are continually editing content in production including uploading new media into the content folder on disk (e.g., uploading a PDF and linking to it within content where the link is in the database). You have run some Wordpress updates in Test a day ago and they seemed good. Today you run them at 9 am in the Live and something odd happens (maybe a timeout, whatever) and the site becomes corrupted. You have automated the rollback. You run the roll-back script which computes the last nightly full backup point then restores the database, then restores last night's media content folder backup over the live folder to revert any lost or corrupted files. To my knowledge that is as good as you can get. Your meantime to recovery should be the speed of your database restore plus the time take to spot the problem and agree to do the restore. This is exactly why you shouldn't have to speak to editing Staff about whether or not they are happy with the roll-back as the site is broken so of course, they would agree to restore the site automatically, rather than have the site down for hours while a possible point fix is investigated and attempted. You can send out a prepared email telling Staff that there was an outage at 9 am such that the site has been restored to the previous nights backup and that they should double-check and repeat any work that they have undertaken in the past twenty-four hours and redo their work as necessary. IMHO that is as close to perfection as an opensource PHP content management system such as Wordpress allows.
F

ECS auto deploy with ECR
Continuous Integration and Delivery (CI, CD) • docker amazon web services amazon ecs • • fbio

2

0
Votes

2
Posts

1
Views

C

I don't think you can trigger re-deployment based on ECS image being updated. You can however do it as part of your Jenkins pipeline - after you push to ECR as a next step in the pipeline can run a script that will reload the task. In fact in my pipelines I deploy the ECS Tasks through CloudFormation templates and the CloudFormation stack update is part of the pipeline. That way I update the ECS Task definition automatically every time I push a new image to non-prod ECR. Hope that helps
On-Prem and Cloud Deployments
Continuous Integration and Delivery (CI, CD) • docker kubernetes continuous deployment • • emmalee

2

0
Votes

2
Posts

1
Views

S

If you can keep one common deployment strategy across both that would be simpler and less effort from the ops side of things. Kubernetes seems to be a great choice for the cloud orchestration layer at this point in time. Does Kubernetes make sense for the on-prem side though? If you're not planning on each on-prem install including 5-10 servers to spread Kubernetes out over then it probably doesn't make sense to use it there. All hope is not lost. You could take the same Docker containers that you ran under Kubernetes and run them yourself for on-prem. You're going to be stuck dealing with service discovery, but if you're only installing on one server that can be solved in some old school way like picking and assigning ports to specific services.
O

Kubernetes show secrets for namespace
Security, Penetration Testing • kubernetes documentation • • Oba22

2

0
Votes

2
Posts

1
Views

S

Found the solution. Searched at the wrong place: -n is part of the core kubectl command: https://kubernetes.io/docs/reference/kubectl/kubectl/ -n, --namespace string If present, the namespace scope for this CLI request So it shows the results for a given namespace if applied.
Kubernetes multi cloud
Continuous Integration and Delivery (CI, CD) • kubernetes rancher • • Bogopo

2

0
Votes

2
Posts

1
Views

(Rancher employee) Kubernetes itself is really not meant for that use-case. A cluster is generally a set of machines in the same provider with close proximity (latency) to each other. Etcd (and therefore API/CLI/UI/scheduling/everything) performance depends heavily on the (worst-case) latency between all members. Only one cloud-provider integration (storage providers, L4 load balancers) can be configured and most assume nodes are all in the same "region" or similar concept. Commonly used network plugins assume adjacency and/or provide no encryption or authentication suitable for communicating across untrusted networks/the internet. Communication between pods/services within the cluster has no consideration for where the "nearest" place to reach a pod for that service is, so latency from a pod to another service can be large (however far apart the two worst nodes are) and unpredictable (sometimes close, sometimes far). (There is an option for nodePorts to always go to a local pod, but if there is no local pod it will just get dropped). You can make a "custom" cluster and add nodes from wherever and do what you're asking in Rancher, but you're not going to have a good time (no matter what product is building the cluster).
How can I use Docker Hub in Terraform?
Continuous Integration and Delivery (CI, CD) • docker terraform • • Analeea

2

0
Votes

2
Posts

1
Views

P

This can be done with docker_registry_image: data "docker_registry_image" "ubuntu" { name = "ubuntu:latest" } resource "docker_image" "ubuntu" { name = "${data.docker_registry_image.ubuntu.name}" pull_triggers = ["${data.docker_registry_image.ubuntu.sha256_digest}"] }
How to have kubernetes (re)build containers on deployment similar to openshifts ImageStream
Continuous Integration and Delivery (CI, CD) • kubernetes automation builds • • briley

2

0
Votes

2
Posts

1
Views

C

You need something that will do basically CI/CD. There are few options (in no particular order): Gitlab + autodeploy (or custom deployment) skaffold + git-sync + kaniko There are more, but basically, you need a component to watch for changes, something that knows how to build an image, and something else that can deploy it (some of these might be done by the same tools) Helm will only do the deployment, but nothing else
O

Change kubernetes resource requests after pod/job has started
Continuous Integration and Delivery (CI, CD) • kubernetes kubectl • • obi

2

0
Votes

2
Posts

1
Views

J

LimitRange for the rescue: by setting both Max limits and LimitRequestRatio for pods users must set limits that are lower than Max or request*ratio or apiserver would return 403 Forbidden.
B

Common config in Kubernetes ConfigMap
Continuous Integration and Delivery (CI, CD) • kubernetes configuration management • • Burma

2

0
Votes

2
Posts

1
Views

R

It is not possible for a ConfigMap to reuse or import other ConfigMaps. You can, however, have many deployments reuse the same ConfigMap. In this case, you should extract out the common configuration to a single ConfigMap and reuse it across deployments while still allowing each individual deployment to have their own specific config.
N

Pros and cons of different deploy strategies
Continuous Integration and Delivery (CI, CD) • git continuous integration deployment workflow continuous deployment • • nishika

2

0
Votes

2
Posts

1
Views

T

Assuming there are no changes in Master that are not in your release branch and you don't rebuild after you merge the code then you could deploy first and then merge to master. If either of those are not true, then merging first would be more common. The process depends on how you handle your branching strategy. If other things could be merged into master that are not part of the release branch then you need to merge first and rerun the pipeline of tests. If master represents production and all new work is now in the release branch then yes, you can deploy then push, or do them as a step in the pipeline assuming the deploy is successful then do the merge.
D

Kubernetes used to orchestrate Containerized Machines
Continuous Integration and Delivery (CI, CD) • docker kubernetes • • derk

2

0
Votes

2
Posts

1
Views

S

You should look at DaemonSets. You can configure it so that the Pods runs on each node of your Kubernetes cluster. Each individual Pod (running your Linux machine) can be exposed to outside network using the IP address of the node on which it is running. My need is more targeted to expose an entire machine on a precise static IP and not just a port. Before getting into further explanation, I should point out that there is nothing like exposing entire machines. Access to any machine is always through a combination of IP address and Port. So you should decide based on which port you would like to access on the container. Example: Let's say I have a 3 node Kubernetes cluster, I can create a DaemonSet with the application/image of my choice. Below names/details are imaginary, but should give an idea on the mapping. ubuntu-daemonset-pod-xyz k8s-node-1 192.168.2.1 ubuntu-daemonset-pod-abc k8s-node-2 192.168.2.2 ubuntu-daemonset-pod-hij k8s-node-3 192.168.2.3 The Pods above can be "exposed" on the IP address of the node on which it is running. That is: ubuntu-daemonset-pod-xyz on 192.168.2.1.
G

Ansible - using facts from one host to perform actions on another host
Continuous Integration and Delivery (CI, CD) • kubernetes ansible • • guilherme

2

0
Votes

2
Posts

1
Views

A

I found a solution - the trick here is delegate_to and delegate_facts: - hosts: all remote_user: ansible become: false tasks: - name: read join line from controlPlane shell: kubeadm token create --print-join-command when: inventory_hostname in groups['workerNodes'] register: joinCmd delegate_to: "{{ item }}" delegate_facts: true with_items: "{{ groups['controlPlane'] }}" - name: join all worker nodes to cluster command: "{{ joinCmd.results[0].stdout }}" become: yes when: inventory_hostname in groups['workerNodes'] The first task kind of reads backwards to my mind - when says 'run this task on all the workerNode hosts...' but delegate_to says '..but actually run it on a different host'. It works for me though (I've only got 1 host in controlPlane group, not sure of outcome with more hosts).

Does `helm upgrade` use rolling restarts for `deployments`, yes/no? if not then what is the default?

Does helm upgrade use rolling restarts for deployments? If not then what is the default?

Suggested Topics

Validate Quality Cobol code - Jenkins, Sonarqube/SonarLint and Rational/Topaz? Continuous Integration and Delivery (CI, CD) • jenkins continuous integration sonarqube • • emerson

Tool preferences for rapidly spinning up and spinning down k8s clusters Continuous Integration and Delivery (CI, CD) • kubernetes testing ansible chef puppet • • terrea

Kubernetes create multiple jobs based on template and list Continuous Integration and Delivery (CI, CD) • kubernetes automation yaml • • magpie

How to set up WordPress CI/CD pipeline Continuous Integration and Delivery (CI, CD) • wordpress pipeline • • Burma

ECS auto deploy with ECR Continuous Integration and Delivery (CI, CD) • docker amazon web services amazon ecs • • fbio

On-Prem and Cloud Deployments Continuous Integration and Delivery (CI, CD) • docker kubernetes continuous deployment • • emmalee

Kubernetes show secrets for namespace Security, Penetration Testing • kubernetes documentation • • Oba22

Kubernetes multi cloud Continuous Integration and Delivery (CI, CD) • kubernetes rancher • • Bogopo

How can I use Docker Hub in Terraform? Continuous Integration and Delivery (CI, CD) • docker terraform • • Analeea

How to have kubernetes (re)build containers on deployment similar to openshifts ImageStream Continuous Integration and Delivery (CI, CD) • kubernetes automation builds • • briley

Change kubernetes resource requests after pod/job has started Continuous Integration and Delivery (CI, CD) • kubernetes kubectl • • obi

Common config in Kubernetes ConfigMap Continuous Integration and Delivery (CI, CD) • kubernetes configuration management • • Burma

Pros and cons of different deploy strategies Continuous Integration and Delivery (CI, CD) • git continuous integration deployment workflow continuous deployment • • nishika

Kubernetes used to orchestrate Containerized Machines Continuous Integration and Delivery (CI, CD) • docker kubernetes • • derk

Ansible - using facts from one host to perform actions on another host Continuous Integration and Delivery (CI, CD) • kubernetes ansible • • guilherme

Does `helm upgrade` use rolling restarts for `deployments`? If not then what is the default?

Validate Quality Cobol code - Jenkins, Sonarqube/SonarLint and Rational/Topaz?
Continuous Integration and Delivery (CI, CD) • jenkins continuous integration sonarqube • • emerson

Tool preferences for rapidly spinning up and spinning down k8s clusters
Continuous Integration and Delivery (CI, CD) • kubernetes testing ansible chef puppet • • terrea

Kubernetes create multiple jobs based on template and list
Continuous Integration and Delivery (CI, CD) • kubernetes automation yaml • • magpie

How to set up WordPress CI/CD pipeline
Continuous Integration and Delivery (CI, CD) • wordpress pipeline • • Burma

ECS auto deploy with ECR
Continuous Integration and Delivery (CI, CD) • docker amazon web services amazon ecs • • fbio

On-Prem and Cloud Deployments
Continuous Integration and Delivery (CI, CD) • docker kubernetes continuous deployment • • emmalee

Kubernetes show secrets for namespace
Security, Penetration Testing • kubernetes documentation • • Oba22

Kubernetes multi cloud
Continuous Integration and Delivery (CI, CD) • kubernetes rancher • • Bogopo

How can I use Docker Hub in Terraform?
Continuous Integration and Delivery (CI, CD) • docker terraform • • Analeea

How to have kubernetes (re)build containers on deployment similar to openshifts ImageStream
Continuous Integration and Delivery (CI, CD) • kubernetes automation builds • • briley

Change kubernetes resource requests after pod/job has started
Continuous Integration and Delivery (CI, CD) • kubernetes kubectl • • obi

Common config in Kubernetes ConfigMap
Continuous Integration and Delivery (CI, CD) • kubernetes configuration management • • Burma

Pros and cons of different deploy strategies
Continuous Integration and Delivery (CI, CD) • git continuous integration deployment workflow continuous deployment • • nishika

Kubernetes used to orchestrate Containerized Machines
Continuous Integration and Delivery (CI, CD) • docker kubernetes • • derk

Ansible - using facts from one host to perform actions on another host
Continuous Integration and Delivery (CI, CD) • kubernetes ansible • • guilherme