Loading presentation...

Present Remotely

Send the link below via email or IM


Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.


OpenShift Core Concepts Part II

No description

Behnam Loghmani

on 21 February 2017

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of OpenShift Core Concepts Part II

Episode 6
Presentation By:
Behnam Loghmani

Core Concepts Part II
Summer 2016
IRAN OpenStack Users Group
Projects and Users
Builds and Image Streams
Running OpenShift in your system
Users and Projects
Interaction with OpenShift Origin is associated with a user. An OpenShift Origin user object represents an actor which may be granted permissions in the system by adding roles to them or to their groups.
Regular users
This is the way most interactive OpenShift Origin users will be represented. Regular users are created automatically in the system upon first login, or can be created via the API.
System users
Many of these are created automatically when the infrastructure is defined, mainly for the purpose of enabling the infrastructure to interact with the API securely. They include a cluster administrator (with access to everything), a per-node user, users for use by routers and registries, and various others. Finally, there is an anonymous system user that is used by default for unauthenticated requests.
Service accounts
These are special system users associated with projects; some are created automatically when the project is first created, while project administrators can create more for the purpose of defining access to the contents of each project. Service accounts are represented with the ServiceAccount object.
behnam loghmani
Every user must authenticate in some way in order to access OpenShift Origin. API requests with no authentication or invalid authentication are authenticated as requests by the anonymous system user. Once authenticated, policy determines what the user is authorized to do.
A Kubernetes namespace provides a mechanism to scope resources in a cluster. In OpenShift Origin, a project is a Kubernetes namespace with additional annotations.
Namespaces provide a unique scope for
Named resources to avoid basic naming collisions.
Delegated management authority to trusted users.
The ability to limit community resource consumption.
Most objects in the system are scoped by namespace, but some are excepted and have no namespace, including nodes,users and projects name.
A project is a Kubernetes namespace with additional annotations, and is the central vehicle by which access to resources for regular users is managed. A project allows a community of users to organize and manage their content in isolation from other communities. Users must be given access to projects by administrators, or if allowed to create projects, automatically have access to their own projects.
Projects can have a separate
, and
The mandatory
is a unique identifier for the project and is most visible when using the CLI tools or API. The maximum name length is 63 characters.
The optional displayName is how the project is displayed in the web console (defaults to name).
The optional description can be a more detailed description of the project and is also visible in the web console.
Pods, services, replication controllers, etc.
Rules for which users can or cannot perform actions on objects.
Quotas for each kind of object that can be limited.
Service accounts
Service accounts act automatically with designated access to objects in the project.

Cluster administrators can create projects and delegate administrative rights for the project to any member of the user community. Cluster administrators can also allow developers to create their own projects.

Developers and administrators can interact with projects using the CLI or the web console.

Builds and Image Streams
Build configurations are characterized by a strategy and one or more sources.
A build is the process of transforming input parameters into a resulting object. Most often, the process is used to transform input parameters or source code into a runnable image. A BuildConfig object is the definition of the entire build process.
Source-To-Image (S2I)
Image Streams
An image stream comprises any number of Docker images identified by tags. It presents a single virtual view of related images, similar to a Docker image repository.
Image streams can be used to automatically perform an action when new images are created. Builds and deployments can watch an image stream to receive notifications when new images are added and react by performing a build or deployment, respectively.
For example, if a deployment is using a certain image and a new version of that image is created, a deployment could be automatically performed.
Any Questions?
Video Channels

Stay in Touch and Join Us
Home Page: OpenStack.ir
Meetup Page: Meetup.com/Iran-OpenStack
Mailing List: OpenStack-ir@Lists.OpenStack.org
Twitter: @OpenStackIR , #OpenStackIRAN
IRC Channel on FreeNode: #OpenStack-ir

Thank You
Behnam Loghmani
Iran OpenStack Community Member

We need to work together to build a better community
Running OpenShift in your system
Full transcript