Translator’s note: This is the 21st article of the series “Cloud Foundry 100-day Challenge selection”. “#100” in the title means that it is 100th (published on November 16, 2015) in the original Japanese series.
Original Author: Jun HORIUCHI (GitHub) (company)
The 100th and last topic of “Cloud Foundry 100-Day Challenge” is Administration Web UI for Cloud Foundry NG (“admin-ui” hereafter), a Sinatra application for operation management that is used officially by Cloud Foundry.
Admin-ui accesses components of Cloud Foundry, then collects and displays various status information. Additionally, it allows addition/deletion of org and space, simple application controls, and making changes to Feature Flags and so on.
It is a tool classified as an incubation in the Cloud Foundry Incubator repository, but at its current state, it already provides the convenience of running simple Cloud Foundry operation management from a browser.
Although it can be deployed with BOSH, as a BOSH Release for admin-ui is available from Cloud Foundry Community, there may be instances when you may want to run the application on Cloud Foundry due to resource restrictions; today’s method may come in handy in such cases.
Basic Information
- Official site
https://github.com/cloudfoundry-incubator/admin-ui - Source code
https://github.com/cloudfoundry-incubator/admin-ui
The procedures from deployment preparation to application behavior check are as follows:
- 1) Modifying Manifest for bosh-lite and Redeploy bosh-lite
- 2) Adding Security Group
- 3) Registering User for admin-ui to UAA
- 4) Retrieving Source Code
- 5) Modifying Source Code
- 6) Deployment
- 7) Checking Application Behavior
1. Modifying Manifest for bosh-lite and Redeploy bosh-lite
Admin-ui accesses components of Cloud Foundry and collects information, but obviously, it also accesses the host for DEA where the application (i.e. admin-ui) container is running.
cf-release v211, the environment we are using in this post, does not allow access to the host in its default configuration; so we will make it allowed by modifying the configuration of the deployment manifest for bosh-lite, the Cloud Foundry environment on which we plan to deploy the application.
Specifically, we will change the configuration of dea_next.allow_host_access to true. If it is already set as true, please ignore this procedure.
The following section will be described with paths for our environment, so please adjust accordingly depending on your environment.
$ vi ./bosh-lite/manifests/cf-manifest.yml
properties:
:
dea_next:
advertise_interval_in_seconds: 5
allow_host_access: true # <- set this value as "true"
allow_networks: []
Once the modification is complete, we will redeploy Cloud Foundry with the bosh command.
$ bosh deployment ~/bosh-lite/manifests/cf-manifest.yml
$ bosh deploy
:
Started 2015-06-30 08:00:11 UTC
Finished 2015-06-30 08:00:50 UTC
Duration 00:00:39
Deployed `cf-manifest.yml' to `Bosh Lite Director'
[[Note]]
In situations where you prefer not to redeploy Cloud Foundry (e.g. you are already running other applications), you can also log in directly to the container (runner) where DEA runs, and edit the configuration file.
* Log in with ssh to the runner container
* Use sudo privilege to open /var/vcap/jobs/dea_next/config/warden.yml, and change configuration of allow_host_access: to true
* Use sudo privilege to monit restart all to reboot components inside runner
2. Adding Security Group
Next, we change the configuration of security groups in order to allow access from the container to each Cloud Foundry component.
We will execute this procedure as a Cloud Foundry user with admin privilege.
The following section will be described for the environment of this post, so please adjust accordingly depending on your environment.
$ cf login -u admin -p admin -o admin -s svcs
Now let’s create a json file that defines the security group.
This time, we will match the configuration to a bosh-lite environment network. Ideally it should be focused to the ports that are being accessed, but since we ran out of time, we make it fully open.
vi admin-ui.security-groups.json
[
{
"protocol": "tcp",
"destination": "10.244.0.134",
"ports": "1-65535"
},
{
"protocol": "tcp",
"destination": "10.244.0.42",
"ports": "1-65535"
},
{
"protocol": "tcp",
"destination": "10.244.0.34",
"ports": "1-65535"
},
{
"protocol": "tcp",
"destination": "10.244.0.138",
"ports": "1-65535"
},
{
"protocol": "tcp",
"destination": "10.244.0.146",
"ports": "1-65535"
},
{
"protocol": "tcp",
"destination": "10.244.0.142",
"ports": "1-65535"
},
{
"protocol": "tcp",
"destination": "10.244.0.6",
"ports": "1-65535"
},
{
"protocol": "tcp",
"destination": "10.244.0.30",
"ports": "1-65535"
},
{
"protocol": "tcp",
"destination": "10.244.0.22",
"ports": "1-65535"
},
{
"protocol": "tcp",
"destination": "10.244.0.26",
"ports": "1-65535"
},
{
"protocol": "tcp",
"destination": "10.244.0.130",
"ports": "1-65535"
}
]
Next we register the defined security group.
$ cf create-security-group admin-ui-security-groups admin-ui.security-groups.json
Creating security group admin-ui-security-groups as admin
OK
$ cf security-groups
Getting security groups as admin
OK
Name Organization Space
#0 public_networks
#1 dns
#2 admin-ui-security-groups
We then bind the registered security group to the space where admin-ui will be deployed.
In the example below, admin-ui-security-groups is bound to a space called horiu-jn within an org called horiu-jn.
$ cf bind-security-group admin-ui-security-groups horiu-jn horiu-jn
:
OK
3. Registering User for admin-ui to UAA
Next, we register groups and users for admin-ui to UAA and grant authorities.
3-1. Install uaac
We will control UAA through uaac, an UAA client.
Therefore, we first install uaac.
$ gem install cf-uaac
$ rbenv rehash
$ uaac --version
UAA client 3.1.4
3-2. Register Groups and Users for admin-ui
We use the installed uaac to register users.
Here, we will replicate the procedures described in the admin-ui README.
First, we prepare for the registration.
$ uaac target http://uaa.10.244.0.34.xip.io
Target: http://uaa.10.244.0.34.xip.io
$ uaac token client get admin -s admin-secret
Successfully fetched token via client credentials grant.
Target: http://uaa.10.244.0.34.xip.io
Context: admin, from client admin
$ uaac client update admin --authorities "`uaac client get admin | \
awk '/:/{e=0}/authorities:/{e=1;if(e==1){$1="";print}}'` scim.write"
scope: uaa.none
client_id: admin
resource_ids:
authorized_grant_types: client_credentials
autoapprove:
action: none
authorities: password.write scim.write clients.write clients.read scim.read
uaa.admin clients.secret
$ uaac token client get admin -s admin-secret
Target: http://uaa.10.244.0.34.xip.io
Context: admin, from client admin
Next, we add groups/users and grant authorities.
$ uaac group add admin_ui.admin
id: 7c07bbc4-d4f4-47cb-ac2f-3370bde143cb
schemas: urn:scim:schemas:core:1.0
meta
version: 0
created: 2015-11-13T10:56:27.239Z
lastmodified: 2015-11-13T10:56:27.239Z
displayname: admin_ui.admin
$ uaac member add admin_ui.admin admin
success
Lastly, we create a client for admin-ui.
uaac client add admin_ui_client \
--authorities cloud_controller.admin,cloud_controller.read,cloud_controller.write,openid,scim.read \
--authorized_grant_types authorization_code,client_credentials,refresh_token \
--autoapprove true \
--scope admin_ui.admin,admin_ui.user,openid \
-s admin_ui_secret
scope: admin_ui.admin openid admin_ui.user
client_id: admin_ui_client
resource_ids:
authorized_grant_types: refresh_token client_credentials authorization_code
autoapprove: true
action: none
authorities: cloud_controller.write openid scim.read cloud_controller.read
cloud_controller.admin
id: admin_ui_client
4. Retrieving Source Code
We clone the source of admin-ui from GitHub.
$ git clone https://github.com/cloudfoundry-incubator/admin-ui.git
$ cd admin-ui/
admin-ui$ ls -a
. bin db Gemfile.lock .gitignore lib README.md .ruby-version .travis.yml
.. config Gemfile .git images LICENSE .rubocop.yml spec
5. Modifying Source Code
Since admin-ui listens the port that is specified in the configuration file given at launch (config/default.yml for bosh-lite), we will modify lib/admin/config.rb to obtain the port from the PORT environment variable to run on Cloud Foundry.
admin-ui$ git diff --no-prefix
diff --git lib/admin/config.rb lib/admin/config.rb
index 2573bf6..5d6f6d4 100755
--- lib/admin/config.rb
+++ lib/admin/config.rb
@@ -195,7 +195,7 @@ module AdminUI
end
def port
- @config[:port]
+ ENV["PORT"] || @config[:port]
end
def receiver_emails
We are finally done with the pre-deployment procedures.
6. Deployment
First, we create a manifest for the deployment.
admin-ui$ vi manifest.yml
---
applications:
- name: admin-ui-100
memory: 512M
instances: 1
command: ~/bin/admin -c ~/config/default.yml
In the above settings, as for command, we use config/default.yml as the configuration file for admin-ui, because it is already configured for bosh-lite.
Once we are done creating the manifest, we cf push.
admin-ui$ cf push
:
requested state: started
instances: 1/1
usage: 512M x 1 instances
urls: admin-ui-100.10.244.0.34.xip.io
last uploaded: Fri Nov 13 10:58:42 UTC 2015
stack: cflinuxfs2
buildpack: Ruby
state since cpu memory disk detail s
#0 running 2015-11-13 07:59:36 PM 0.0% 80M of 512M 0 of 1G
The deployment is successful.
7. Checking Application Behavior
We get the log in page when we access the application URL (see above) via a Web browser.
The initial username/password should be admin/admin unless you have modified the manifest of Cloud Foundry deployment for bosh-lite, so we enter this to log in.
Upon a successful log in, you will see quite a few tabs lined up on the upper end. Here, we will highlight a few from each category.
First, when we open Apps, we find a list of applications pushed by all users.
Although we have no screenshot, we were successful in stopping and deleting applications with the buttons up top.
Next, we open Service Brokers.
We see a list of services that have played active roles in the “Cloud Foundry 100-Day Challenge”.
We move on, remembering to thank them for their contributions.
The Components tab comes in handy when you want to check the status of each Cloud Foundry component.
You will be able to find the level of details that can be checked with the bosh vms command.
Further details can be found with the tabs for each component.
If you click a value in the Name column, details will be shown in the space to the bottom. Additionally, if you click on the value of the URI row in this details table, you can also get its raw data of varz.
You can also view the content of a log file if you specified it in the configuration file given at launch (config/default.yml in this case).
The default configuration only specifies the log file of admin_ui itself, but you can also make it display logs for each component by adding it to the configuration.
The way how to configure admin-ui can be found in the README.
Lastly, we take a look at the Feature Flag tab.
Check off the Feature you would like to control, and use the Enable/Disable button to alter the setting.
Here, we switched app_scaling to disabled.
When we scaled this application after changing the flag to disabled, as expected, we failed to scale and received a Feature Disabled output.
admin-ui$ cf scale admin-ui-100 -i 2
Scaling app admin-ui-100 in org horiu-jn / space horiu-jn as horiu-jn...
FAILED
Server error, status code: 403, error code: 330002, message: Feature Disabled: app_scaling
When we switched back it to enabled, we were able to scale without any issues.
admin-ui$ cf scale admin-ui-100 -i 2
Scaling app admin-ui-100 in org horiu-jn / space horiu-jn as horiu-jn...
OK
Software Used in This Post
- cf-release(v211)
https://github.com/cloudfoundry/cf-release/tree/v211
(https://github.com/cloudfoundry/cf-release/tree/2121dc6405e0f036efa4dba963f7f49b07e76ffa) - bosh-lite
https://github.com/cloudfoundry/bosh-lite/tree/552dc6869600c5350eb7ffb4fb9c9c5e79e3889d - CF CLI (v6.12.0-8c65bbd-2015-06-30T00:10:31+00:00)
https://github.com/cloudfoundry/cli/tree/v6.12.0 (https://github.com/cloudfoundry/cli/tree/8c65bbd4d243cbbc9bdbf2ec2a3b0e094c094f48) - admin-ui
https://github.com/cloudfoundry-incubator/admin-ui/tree/17c429c28891673c057dd69e52bdeb3efc08376c
