Hello, and welcome to Apigee Edge Platform Operation Part Two.

Today, we will cover the following topics,

code with config and component reachability.

The first topic we are going to explore is code with config.

After installation, Edge uses a combination

of properties files and apigee-service actions.

For example, to configure SSL on the management API,

you would edit the properties files to set the appropriate values,

certificate paths, et cetera.

When such changes are made,

you would use the apigee service to restart the component and apply the changes.

This editing of properties files is referred to in apigee Edge as "code with config."

It consists of a key value lookup based on settings and the properties files.

These keys are known as tokens.

To reconfigure Edge, you set tokens in custom properties files.

This method allows Edge to ship with a set of

default values which can be overridden by the installer,

but also by the customer.

Install time overrides are written to /opt/apigee/token.

Customer overrides are written to /opt/apigee/customer.

Code with config tokens are read from

each location and merged into a final runtime config.

Customer settings type priority installer settings come next.

And if no overrides are found,

then the default settings become the runtime values.

Final runtime configuration can be seen in the config directory of the component.

The actual property file we create to override the install is set

values is created in /opt/apigee/customer application.

Each Edge component should have its own file

named after the application without its prefix.

E.g., message-processor.properties or router.properties.

By default, the /opt/apigee/customer application directory is empty.

When you need to override a property,

you create the properties file and change

the user and group ownership to the apigee-service account.

To set a component property,

edit the properties file and provide the token name a new value.

Once complete, save the file and use apigee-service to restart the component.

In the example, you can see the settings for

changing the minimum or maximum Java hape size,

as well as the setting for the default class metadata size.

One thing to note is the apigee guarantee not to touch any files

in /opt/apigee/customer application during any upgrade process.

So you can be confident that any changes you make will be persistent.

You can determine all available tokens by viewing the properties file for each component.

This file is located in /opt/apigee/component name/token.

Any token here can be overridden.

Before overriding the token,

you can determine the currently configured value by using apigee-service,

providing the component name,

configure, menu search, and providing the token name.

This commands such as the properties file hierarchy to determine the current value.

In this example, we check the HTTP request line limit for the router component,

and we can see that the current value is set to 4k.

Finally, we'll talk about a few maintenance operations.

Firstly, let's look at the router and message processor reachability.

During routine maintenance such as several restarts or upgrades,

it is good practice to disable reachability to the server.

When reachability is disabled,

no traffic is directed to the server.

In the first example,

we see a normal running system.

All components are reachable and traffic flows from the load balancer to all components.

In the next example,

reachability on the router has been disabled,

making the load balancer only send traffic to the remaining router in the pool.

In the third example,

reachability of a message processor has been disabled.

So, the routers automatically only send traffic to the reachable message processor.

In this final example,

one router and one message processor have reachability disabled.

Only a single path exists but traffic still flows.

Following this approach, allows maintenance to happen

even during busy times with no impact and uses.

The approach taken for disabling the routers and message processors is different.

Let's first look at routers.

Typically in a production environment,

you have a load balancer sat in front of a number of routers.

You would configure your load balancer to use port

15999 as the health check port for the routers.

If the port becomes unavailable,

the router should be removed from the load

balancing pool until it becomes available again.

An easy way to make the router unreachable is to use

the IP tables or firewalld to block access to the port as shown.

Once maintenance is complete,

reverse the change in order to allow the load balancer to rehab the router to the pool.

Next, we come on to message processors.

To disable reachability on a message processor,

simply stop the service using the apigee-service utility.

The message processor will first process any pending messages before it shuts down.

After this time, routers will send traffic to any remaining message processors.

To restart the message processor,

again use the apigee-service utility to start the service.

You can also execute the apigee-service utility,

this time passing it the wait_for_ready option.

When the message processor has finished starting up and is ready to process commands,

you'll see a message stating that the service is up.

Thank you. This is the end of part two.

Platform Operations Part 2

On Premises Management, Security, and Upgrade with Google Cloud's Apigee API Platform

Conheça os instrutores