3 ms·

Tried OpenShift last time and their cartridge model didn't make sense. What has changed since then?

yebyen 9y ago
Literally everything. Cartridges are OpenShift v2, "images" in v3 are literally the same concept as a Docker image. You can check out this link[1] for more about what's changed. My first instinct trying OpenShift v3 Developer Preview was to slap helm on it and see if I could deploy my Kubernetes projects. Turns out that Helm does not have much of a security model to speak of, and this was problematic to enabling support for Helm in OpenShift v3 where multi-tenancy was one of the concerns they wanted to address right away. I got with claytonc in the #openshift-dev channel on freenode and he explained all of this to me, the long story short is that Helm on OpenShift is not well supported but that you can use it if you are willing to give it a service account with editor access to the whole cluster and make some other small changes like setting TILLER_NAMESPACE to something other than kube-system. Instead, OpenShift basically uses the Kubernetes model with some additional primitives for deployments and builds. You define a BuildConfig (or let the point-and-click interface do it for you). Builds produce images, and images go into an ImageStream. A DeploymentConfig maps deployments to ImageStreams. [2] The rest of the way down the stack, your deployment looks very similar to a regular Kubernetes deployment (except it's not using the Kubernetes deployment primitive, I believe that OpenShift implemented their own formal concept of Rolling Updates on DeploymentConfig before Kubernetes released the modern Deployment/ReplicaSet primitives that many k8s users are using for this now.) It is almost Kubernetes under the hood (but not quite, in subtly incompatible ways that depending on your size and current level of investment into Kubernetes, you might have an easy time or a hard time getting over.) If you're looking for a short list of things that have changed from OpenShift v2 to v3, there isn't one because they are not really directly related products other than by name[3]. [1]: https://access.redhat.com/documentation/en-us/openshift_enterprise/3.1/html/release_notes/release-notes-v2-vs-v3 https://access.redhat.com/documentation/en-us/openshift_ente... [2]: https://docs.openshift.org/latest/dev_guide/deployments/how_deployments_work.html https://docs.openshift.org/latest/dev_guide/deployments/how_... [3]: http://stackoverflow.com/questions/32477650/openshift-v3-vs-openshift-v2 http://stackoverflow.com/questions/32477650/openshift-v3-vs-...

Literally everything. Cartridges are OpenShift v2, "images" in v3 are literally the same concept as a Docker image. You can check out this link[1] for more about what's changed. My first instinct trying OpenShift v3 Developer Preview was to slap helm on it and see if I could deploy my Kubernetes projects. Turns out that Helm does not have much of a security model to speak of, and this was problematic to enabling support for Helm in OpenShift v3 where multi-tenancy was one of the concerns they wanted to address right away. I got with claytonc in the #openshift-dev channel on freenode and he explained all of this to me, the long story short is that Helm on OpenShift is not well supported but that you can use it if you are willing to give it a service account with editor access to the whole cluster and make some other small changes like setting TILLER_NAMESPACE to something other than kube-system. Instead, OpenShift basically uses the Kubernetes model with some additional primitives for deployments and builds. You define a BuildConfig (or let the point-and-click interface do it for you). Builds produce images, and images go into an ImageStream. A DeploymentConfig maps deployments to ImageStreams. [2] The rest of the way down the stack, your deployment looks very similar to a regular Kubernetes deployment (except it's not using the Kubernetes deployment primitive, I believe that OpenShift implemented their own formal concept of Rolling Updates on DeploymentConfig before Kubernetes released the modern Deployment/ReplicaSet primitives that many k8s users are using for this now.) It is almost Kubernetes under the hood (but not quite, in subtly incompatible ways that depending on your size and current level of investment into Kubernetes, you might have an easy time or a hard time getting over.) If you're looking for a short list of things that have changed from OpenShift v2 to v3, there isn't one because they are not really directly related products other than by name[3]. [1]: https://access.redhat.com/documentation/en-us/openshift_enterprise/3.1/html/release_notes/release-notes-v2-vs-v3 https://access.redhat.com/documentation/en-us/openshift_ente... [2]: https://docs.openshift.org/latest/dev_guide/deployments/how_deployments_work.html https://docs.openshift.org/latest/dev_guide/deployments/how_... [3]: http://stackoverflow.com/questions/32477650/openshift-v3-vs-openshift-v2 http://stackoverflow.com/questions/32477650/openshift-v3-vs-...