Organization and Environment Maintenance

Edge for Private Cloud v. 4.17.05

This section covers various administrative operations, for example, creation, management and
removal of Apigee organizations, environments and virtual hosts in an Apigee Edge for Private
Cloud installation.

Checking Status of Users, Organization
and Environment

Management Server plays a vital role in holding all other components together in an
on-premises installation of Edge Private Cloud. You can check for user, organization and
deployment status on the Management Server by issuing the following CURL commands:

The system should display 200 HTTP status for all calls. If these fail, do the following:

Check the Management Server logs at /opt/apigee/var/log/apigee/management-server for
any errors.

Make a call against Management Server to check whether it is functioning
properly.

Remove the server from the ELB and then restart the Management Server:/opt/apigee/bin/apigee-service
management-server restart

About using config files

The commands shown below take a config file as input. For example, you pass a config file to
the setup-org command to define all the properties of the organization, including the environment
and virtual host.

For a complete config file, and information on the properties that you can set in the config
file, see Onboard an organization.

About setting up a virtual host

A virtual host on Edge defines the domains and Edge Router ports on which an API proxy is
exposed, and, by extension, the URL that apps use to access an API proxy. A virtual host also
defines whether the API proxy is accessed by using the HTTP protocol, or by the encrypted HTTPS
protocol.

Use the scripts and API calls shown below to create a virtual host. When you create the
virtual host, you must specify the following information:

The name of the virtual host that you use to reference it in your API
proxies.

The port on the Router for the virtual host. Typically these ports start
at 9001 and increment by one for every new virtual host.

The host alias of the virtual host. Typically the DNS name of the virtual
host.

The Edge Router compares the Host header of the incoming request to the list of host aliases as
part of determining the API proxy that handles the request. When making a request through a
virtual host, either specify a domain name that matches the host alias of a virtual host, or
specify the IP address of the Router and the Host header containing the host alias.

For example, if you created a virtual host with a host alias of
myapis.apigee.net on port 9001, then a cURL request to an API
through that virtual host could use one of the following forms:

If you have a DNS entry for myapis.apigee.net:curl
http://myapis.apigee.net:9001/{proxy-base-path}/{resource-path}

If you do not have a DNS entry for myapis.apigee.net:curl
http://<routerIP>:9001/{proxy-base-path}/{resource-path} -H 'Host:
myapis.apigee.net'

In the second form, you specify the IP address of the Router, and pass the host alias in the
Host header.

Note: The curl command, most browsers, and many other utilities automatically
append the Host header with the domain as part of the request, so you can actually use a curl
command in the form:curl
http://<routerIP>:9001/{proxy-base-path}/{resource-path}

Options
when you do not have a DNS entry for the virtual host

One option when you do not have a DNS entry is to set the host alias to the IP address of the
Router and port of the virtual host, as <routerIP>:port. For example:

192.168.1.31:9001

When you make a curl command in the form below:

curl http://<routerIP>:9001/{proxy-base-path}/{resource-path}

This option is preferred because it works well with the Edge UI.

If you have multiple Routers, add a host alias for each Router, specifying the IP address of
each Router and port of the virtual host.

Alternatively, you can set the host alias to a value, such as
temp.hostalias.com. Then, you have to pass the host header on every request: