Decorators in Python

 When the Source build strategy is invoked by oc new-app, it sets up two steps. The first step is to run the build using S2I, combining the source files with the builder image to create the runnable image. The second step is to deploy the runnable image and start up the web application. You can perform the build step separately by running the oc new-build command instead of the oc new-app command:  $ oc new-build --name blog \ python:3.5~https://github.com/openshift-katacoda/blog-django-py The output looks similar, but the deploymentconfig and service resource objects are not created. When the build has completed, the runnable image created is saved away as the image stream called blog. To deploy that image, the oc new-app command is used, but this time the name of the imagestream created by the build is supplied instead of the details of the builder image and repository URL: $ oc new-app blog  Triggering a New Build In the event that the source files used as input to th...

  Authentication : OpenShift has several built-in  authentication  methods to allow granular access to OpenShift projects: Local authentication LDAP authentication Request header authentication Keystone authentication GitHub authentication Internal Image Registry : OpenShift uses an  internal  registry to store images in OpenShift that are ready to be deployed on OpenShift nodes. It is also used for S2I builds. GUI and web console : OpenShift  provides  an easy-to-use  web  interface, powerful enough to create, build, deploy, update, and troubleshoot OpenShift projects and microservice applications running inside OpenShift. SCM Integration : OpenShift has built-in  integration  with Git. This solution is tightly coupled with an image builder. Image builders : Process that is used to transform image parameters or  source  code into a runnable image. CI/CD Integration : OpenShift  provides  very flexible integratio...

  PaaS is the next generation of platforms to deliver applications in a quick and automated manner in production. With PaaS, the application delivering process looks very simple—there is no need to install and configure an application platform for web servers, databases, and so on. It is provided by the platform itself, OpenShift in our case. This means that you just need to upload your application code and database structures; the rest of it will be taken care of by PaaS OpenShift leverages Kubernetes as a container  management  platform and adds several new important components and capabilities. Some of them are: Self-service Portal and Service Catalog Build and application deployment automation Built-in registry service Extended application routing  IaaS, PaaS, and SaaS cloud comparison

  Both SSH and Personal Access Tokens are ways to securely access github without using password. SSH: SSH is the traditional approach using SSH protocol that verifies the client with the help of public key private key model and establishes a secure connection. This mechanism enables us to push / pull commits into/ from github repositories without use of passwords. It requires one time setup, and periodically updating the SSH keys. Personal Access Token: The personal access token uses HTTPS protocol. This protocol unlike SSH is not blocked by firewalls. This requires an additional credential manager configuration to remember credentials and use them for git remote operations (push, pull, etc). The  scope  of the token should be selected properly at the time of creation to limit the usage of token for specific requirements. The personal access token additionally enables us to use the APIs exposed by github using curl or any other REST client. This also requires one time set...

.s2i /environment

Re: oc new-app --docker-image vs oc create deployment image Hi TheHero I completely agree, that sentence may be misleading. Just adding one note: the term "application" in OpenShift (and in Kubernetes in general) is somehow overloaded. When talking about resources, an "application" is just a bunch of resources with the same value for the "app" label. In other contexts, "application" refers to the set of program components deployed with a common purpose.  But, again, I agree with you that the sentence can be improved. KR    oc new-app --docker-image vs oc create deployment image The main difference between using "oc new-app" and "oc create deployment" is the number of resources created. "oc create deployment" creates a "DeploymentConfiguration" resource, getting the image from the registry (quay.io in this case) and deploying as needed (i.e. one replica by default). "oc new-app" creates a bunch of ...

 Deploy App    Object What it does BuildConfig    Builds a Docker image inside OpenShift from our source code, and  push it to OpenShift’s internal Docker registry. In this tutorial, we’re  going to use the  Source-to-Image (S2I)  method for building an image. Deployment Deploys the image. It creates a set of  Pods  to run the image. (see            some  Deployment examples ) Service This load-balances traffic across the  Pods . Route Exposes the app outside the OpenShift cluster.  

  Image Streams: A single place to reference a set of related images An image stream is a single pointer to a set of related images. One image stream can contain many different tags ( latest ,  develop ,  1.0 , etc), each of which points to an image in a registry. Whenever you want to deploy an application in a project, instead of having to hardcode the registry URL and tag, you can just refer to the image stream tag. If the source image changes location in future, you just need to update the image stream definition, instead of updating all your deployments individually! This is how the Red Hat images work in OpenShift. The Red Hat images are installed as image streams in the  openshift  project. You can reference them from any other project in the cluster.

ways-to-build-applications-in-openshift oc new-build <builder-image>~<git-repository> --name=<optional>

  When using the source workflow , developers would: Clone the project to a local folder, so they can change the code to their liking and maybe test it outside of OpenShift. Commit and push any changes to the origin git repository. Log in to OpenShift and create a new project. Use the  oc new-app  command to build the container image and create the OpenShift resources that describe the application. The OpenShift client command creates OpenShift resources to build and deploy the application. The build configuration resource starts a source build that runs Maven to generate the application package (JAR) and create the application container image containing the application package. Expose the application service to the outside world. Use either curl or a web browser to test the application. The  oc new-app  command will create all of those objects for you. Just pass it your Git repo URL, and optionally a  context-dir  (if your code is in a subfolder), an...