OpenShift v3 (Mega Tutorial) – Part 3 – CLI

OpenShift

OpenShift v3 – CLI

OpenShift offers two different ways to connect the API: command line and via Web. Lets start taking a look the  CLI (Command Line Interface).

CLI

With OpenShift we have two tools to manage the cluster:

  • oc: the basic tool; developed to create and manage projects and applications. Is a tool for the developers.
  • oadm: the tool for cluster management. It can manage resources as limits, policies, security.

Both are availables in any host of the cluster we have been created, but it can also be downloaded and use them in a remote machine. There are two versions: oc only, for Linux/Mac/Windows platforms, and oc+oadm exclusively for Linux You can download them here.

GoLang

GoLang is a programming language developed by Google and used in the Kubernetes project; as OpenShift include Kubernetes, is also written in Go, as well as the command line tools. This CLI tools connect the OpenShift API through HTTPS RESTFUL calls.

 

Authentication

The API calls requires to be authenticated with a token. The authentication mechanism is defined in the main config file of the master in /etc/origin/master/master-config.yaml, section oauthConfig:

oauthConfig:
 assetPublicURL: https://master.osc.test:8443/console/
 grantConfig:
   method: auto
 identityProviders:
 - challenge: true
   login: true
   mappingMethod: claim
   name: allow_all
   provider:
     apiVersion: v1
     kind: AllowAllPasswordIdentityProvider
 masterCA: ca-bundle.crt
 masterPublicURL: https://master.osc.test:8443
 masterURL: https://master.osc.test:8443
 sessionConfig:
   sessionMaxAgeSeconds: 3600
   sessionName: ssn
   sessionSecretsFile: /etc/origin/master/session-secrets.yaml
 tokenConfig:
   accessTokenMaxAgeSeconds: 86400
   authorizeTokenMaxAgeSeconds: 500

In section provider->kind appears the mechanism. It is configured by default as AllowAllPasswordIdentityProvider, that allows access for the master’s root user to the API without a token, as there is an authentication certificate.

There are several authentication providers like next list among others:

  • HTTP: hace uso de un fichero htpasswd
  • LDAP: que se conectará a un servidor LDAP
  • Keystone: hace uso de los keystone de autenticación de OpenStack
  • Google: permite loguearnos con la cuenta de Google
  • Github: permite loguearnos con la cuenta de Github

I am going to use HTTP for easy management, but you can find relevant use information in OpenShift documentation.

 

HTPasswdPasswordIdentityProvider

First we need to install in Master the necessary tools for htpasswd file creation.

yum install -y httpd-tools

Now the creation of the file, including user demo

htpasswd -c /etc/origin/master/.htpasswd demo
New password: <demo>
Re-type new password: <demo>
Adding password for user demo

Lets edit config file

vim /etc/origin/master/master-config.yaml
...
oauthConfig:
 assetPublicURL: https://master.osc.test:8443/console/
 grantConfig:
   method: auto
 identityProviders:
 - challenge: true
   login: true
   mappingMethod: claim
   name: my_htpasswd 
   provider:
     apiVersion: v1
     kind: HTPasswdPasswordIdentityProvider
     file: /etc/origin/master/.htpasswd
 masterCA: ca-bundle.crt
 masterPublicURL: https://master.osc.test:8443
...

We must restart the service to apply the changes

systemctl restart origin-master

To demostrate real-like usage I am going to install the oc tool in the gateway machine

cd /tmp/
curl -L https://github.com/openshift/origin/releases/download/v1.2.1/openshift-origin-client-tools-v1.2.1-5e723f6-linux-64bit.tar.gz|tar xz
mkdir ~/bin
mv openshift-origin-client-tools-v1.2.1-5e723f6-linux-64bit/oc ~/bin
rm -rf openshift-origin-client-tools-v1.2.1-5e723f6-linux-64bit/
cd ~
oc login master.osc.test
The server uses a certificate signed by an unknown authority.
You can bypass the certificate check, but any data you send to the server could be intercepted by others.
Use insecure connections? (y/n): y
Authentication required for https://master.osc.test:8443 (openshift)
Username: demo
Password: <demo>
Login successful.

You don't have any projects. You can try to create a new project, by running

 $ oc new-project <projectname>

Welcome! See 'oc help' to get started.

Lets follow the hints given by the commands to create a project and our first application:

oc new-project test
Now using project "test" on server "https://master.osc.test:8443".

You can add applications to this project with the 'new-app' command. For example, try:

 $ oc new-app centos/ruby-22-centos7~https://github.com/openshift/ruby-hello-world.git

to build a new hello-world application in Ruby.

oc new-app centos/ruby-22-centos7~https://github.com/openshift/ruby-hello-world.git
--> Found Docker image 62e0acf (7 days old) from Docker Hub for "centos/ruby-22-centos7"

 Ruby 2.2 
 -------- 
 Platform for building and running Ruby 2.2 applications

 Tags: builder, ruby, ruby22

 * An image stream will be created as "ruby-22-centos7:latest" that will track the source image
 * A source build using source code from https://github.com/openshift/ruby-hello-world.git will be created
 * The resulting image will be pushed to image stream "ruby-hello-world:latest"
 * Every time "ruby-22-centos7:latest" changes a new build will be triggered
 * This image will be deployed in deployment config "ruby-hello-world"
 * Port 8080/tcp will be load balanced by service "ruby-hello-world"
 * Other containers can access this service through the hostname "ruby-hello-world"

--> Creating resources with label app=ruby-hello-world ...
 imagestream "ruby-22-centos7" created
 imagestream "ruby-hello-world" created
 buildconfig "ruby-hello-world" created
 deploymentconfig "ruby-hello-world" created
 service "ruby-hello-world" created
--> Success
 Build scheduled, use 'oc logs -f bc/ruby-hello-world' to track its progress.
 Run 'oc status' to view your app.
oc get pods
NAME                     READY  STATUS      RESTARTS    AGE
ruby-hello-world-1-build 0/1    Completed   0           2m
ruby-hello-world-1-cakcb 1/1    Running     0           10s


oc get svc
NAME               CLUSTER-IP     EXTERNAL-IP   PORT(S)    AGE
ruby-hello-world   172.30.140.4   <none>        8080/TCP   3m

As we do not have access to thw Web console neither we have been configured an external IP, we are going to access to the application with the curl command. This operation must be done from one of the nodes of the cluster because we need to use the OpenShift SDN network. The example is run from Master:

curl -s 172.30.140.4:8080|head -n 20
<!DOCTYPE html>
<html>
<head>
 <!-- Latest compiled and minified CSS -->
 <link rel="stylesheet" href="https://maxcdn.bootstrapcdn.com/bootstrap/3.3.0/css/bootstrap.min.css">

 <!-- Optional theme -->
 <link rel="stylesheet" href="https://maxcdn.bootstrapcdn.com/bootstrap/3.3.0/css/bootstrap-theme.min.css">

 <!-- Latest compiled and minified JavaScript -->
<img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" data-wp-preserve="%3Cscript%20src%3D%22%2F%2Fcode.jquery.com%2Fjquery-1.11.0.min.js%22%3E%3C%2Fscript%3E" data-mce-resize="false" data-mce-placeholder="1" class="mce-object" width="20" height="20" alt="&amp;lt;script&amp;gt;" title="&amp;lt;script&amp;gt;" />
<img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" data-wp-preserve="%3Cscript%20src%3D%22https%3A%2F%2Fmaxcdn.bootstrapcdn.com%2Fbootstrap%2F3.3.0%2Fjs%2Fbootstrap.min.js%22%3E%3C%2Fscript%3E" data-mce-resize="false" data-mce-placeholder="1" class="mce-object" width="20" height="20" alt="&amp;lt;script&amp;gt;" title="&amp;lt;script&amp;gt;" />

  <title>Hello from OpenShift v3!</title>
</head>
<body>


<div class="page-header" align=center>


<h1> Welcome to an OpenShift v3 Demo App! </h1>


</div>



 

 

Web Console

The Web console is configured by default in Master and the access is defined in “ assetPublicURL: https://master.osc.test:8443/console/ ” inside the master config file. The default authentication provider does not allow to connect because it does not provided tokens, and the API requires one. As we have been configured HTTP previously, we can access now with demo user.

In my testing environment I am going to create a proxy socks via a SSH connection to gw.osc.test, so I do not change the DNS configuration in my local machine.

Neither I want to change settings in my browser so I will use a plugin called Foxy Proxy, available for Firefox and Chrome among others. This plugin allows configuration of proxies and fast switch between them. I am going to use plugin “Basic” version, you can get it here for Firefox and Chrome. I will do the proxy with Gateway VM with command ” ssh -D 1080 gw.osc.test

Te first attempt will inform us that the connection is not secure due a selfsigned certificate from master. Just trust the certificate and we can login with user  demo

Origin-v3-Web-Proyect

We see the project we created before. If we click on it we see the objects belonging to the project.

origin-v3-web-objects

There is a side bar that give us access to:

  • Overview: An overview of all the objects inside the project
  • Browse: We can browse by categories the objects, like pods, services, routers, etc.
  • Settings: As it says, the project parameters

As demo user has not been configured is only able to create a project and manage the objects inside, but cannot access to other projects nor manage the cluster. We will see security settings in other post.

The application we have been created is accesible from SDN network only, so we can access it from any host inside the cluster, but no external hosts. We can assign it an external IP, but this requires an IP for every application or complex rules. Master has deployed a pod called router that is in charge to route request with subdomain configured in master-confiig.yaml “subdomain” section. In our example we configured the subdomain apps.osc.test.

If we want to use this route in Overview there is an object SERVICE called ruby-hello-world, and just at the right there is a link Create router, lets click on it

origin-v3-web-route

This allows us to create a router and configure several paremeters as:

  • Name: The route name. Usually the application name
  • Hostname: The hostname for access to the application. It is necessary a FQDN resolved by the DNS to the address where the router is deployed, to Master in our case. If blank it will take default value as <app-name>-<project-name>.<default-subdomain>, in our example ruby-hello-world-test.apps.osc.test
  • Path: The application web context
  • Target Port: Port redirection from host to pod

We do not change anything and click in Create

Now we see in Overview the object SERVICE has changed and now appears with the application hostname

origin-v3-web-route-1

If we click on it we access the application

origin-v3-web-app

Of course is very simple, but at least it is working.

 

Some common commands used:

  • oc
    • get: fetch basic information
      • pods
      • nodes
      • routes
      • projects
      • endpoints
      • replicationcontrollers
      • deploymentconfigs
      • imagestreams
    • describe: fetch detailed information
      • pods
      • nodes
      • routes
      • projects
      • endpoints
      • replicationcontrollers
      • deploymentconfigs
      • imagestreams
    • create: component creation
    • delete: component deletion

 

 

That is all in this post. Next we will see more commands and usage to create and manage applications and cluster, but we need to see how to manage OpenShift security policies. See you soon.

Leave a Reply

Your email address will not be published. Required fields are marked *