-
Notifications
You must be signed in to change notification settings - Fork 1.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Refine deployment docs, add advanced strategies #2890
Conversation
deployment configurations are propagated appropriately. If the existing | ||
deployment strategies are not suited for your use-case and you have the | ||
need to run manual steps during the lifecycle of your deployment, then you | ||
should consider creating a custom strategy. See the section below on custom |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can we add link to that section here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done
@@ -99,46 +105,47 @@ spec: | |||
<4> An xref:image-change-trigger[image change trigger] trigger causes a new replication controller to be | |||
created each time a new version of the `origin-ruby-sample:latest` image stream tag is available. | |||
<5> The xref:rolling-strategy[Rolling strategy] is the default way of deploying your pods. May be omitted. | |||
<6> The existing running deployment will not be paused. Pod template or image changes cover the full spectrum of changes on which deployments currently run. | |||
<7> Revision history limit is the limit of old replication controllers you want to keep around for rolling back. May be omitted. If omitted, old replication controllers will not be cleaned. | |||
<6> Pause a deployment configuration. This allows for multiple changes on the pod template before actually rolling it out. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
maybe describe that this will mute the ConfigChange trigger and ImageChange trigger?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done
|
||
---- | ||
$ oc deploy --latest dc/<name> | ||
---- | ||
|
||
[NOTE] | ||
==== | ||
If a deployment is already in progress, the command will display a | ||
If a deployment process is already in progress, the command will display a |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
maybe mention --cancel
here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We already display the suggestion when somebody hits this.
==== | ||
|
||
[[retrying-a-deployment]] | ||
|
||
== Retrying a Deployment | ||
|
||
To retry the last failed deployment: | ||
If the current revision of your deployment configuration failed to deploy, you can |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
maybe worth to describe how to debug failures? (maybe worth to add a section dedicated for that)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I will open a follow-up issue since this is out of scope for this PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i'm ok with follow up
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
==== | ||
|
||
[[deployment-triggers-using-the-command-line]] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
reminder for future me: describe the oc set image
here (it will trigger deployment and maybe used to manually controller what image will be deployed)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think we want to intermingle set image
with triggers. This will push users to use set image
which is 1) not needed and 2) will get us into pretty weird states if we bypass triggers.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
At the very least we need to identify why would somebody use set image
while using a trigger and need to sort out if we can fix any weirdness that comes along with bypassing triggers.
=== When to use a recreate deployment? | ||
|
||
* When you must run migrations or other data transformations before your new code starts | ||
* When you don't support having new and old versions of your application code running at the same time |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
maybe add the RWO volume here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done
|
||
=== Blue-Green Deployment | ||
|
||
Blue-Green deployments involve running two versions of an application at the same time and moving production traffic from the old version to the new version ([more about blue-green deployments](http://martinfowler.com/bliki/BlueGreenDeployment.html)). There are several ways to implement a blue-green deployment in {product-title}. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
point to example below?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We don't point from the description of the strategy to its example in any of the other descriptions and I don't think we need to (you just need to scroll down and finish reading about the strategy you are reading:))
Blue-Green deployments involve running two versions of an application at the same time and moving production traffic from the old version to the new version ([more about blue-green deployments](http://martinfowler.com/bliki/BlueGreenDeployment.html)). There are several ways to implement a blue-green deployment in {product-title}. | ||
|
||
|
||
=== When to use a blue-green deployment? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Blue-Green for consistency
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok
1. Create two copies of the example application | ||
|
||
--- | ||
$ oc new-app openshift/deployment-example:v1 --name=bluegreen-example-old |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
maybe the name should be example-blue
and example-green
? ;-)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
updated
$ oc edit route/bluegreen-example | ||
--- | ||
|
||
Change `spec.to.name` to `bluegreen-example-new` and save and exit the editor. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can you provide a patch command for this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done
LGTM @openshift/team-documentation ship it :-) |
@adellape ping |
@mfojtik re https://trello.com/c/oAlPryPh/793-3-need-to-document-how-to-use-upstream-deployments I guess we want a section in our docs that compares DCs vs D, is that right? Would you say that this PR blocks the Trello card? |
@Kargakis it does not, the trello card is about documenting the upstream deployments and comparing them with Origin deployments. |
@adellape ping |
@adellape note that all these changes are effective in 3.3 - not sure why this has the 3.4 flag |
I would like to move forward with this so I can lay on top some minor changes for 3.4. Thanks. |
@ahardin-rh - PTAL. |
@adellape @ahardin-rh Might be worth looking at this issue and putting in that info in the followup (or in a separate followup): |
@ahardin-rh can you have a look? |
continuing work in #3149 |
@mfojtik I would like this merged before we proceed with https://trello.com/c/oAlPryPh/793-3-need-to-document-how-to-use-upstream-deployments
@smarterclayton this squashes https://github.com/openshift/origin/blob/master/examples/deployment/README.md in openshift-docs.