Layer7 API Management

  • 1.  Full Gateway Migration

    Posted Oct 19, 2017 08:06 PM

    Hello Folks,

    We are doing Gateway Migration from older version to newer version and wondering if we use GMU command to migrateOut --all command we will get the "Gateway Management Service", "Rest Management Service" and the API Portal components like API Plan Fragment, Account Plan Fragment etc., and when we migrateIn they will be migrated to the new gateway. Will that be sufficient or should we ignore and publish all of them manually on the new server?

     

    What is the best practice about it?

     

    Thank you!



  • 2.  Re: Full Gateway Migration
    Best Answer

    Posted Oct 20, 2017 09:56 AM

    Hello Samjon,

    Although those policies and services will work, it is a best practice to publish those with newer versions. So upgrade, publish new services and migrate to the next environment. I am not sure if the ids will match(I believe they will) but if they don't just map with name so you don't need to change policies encapsulating policies like "Account/API Plan fragments". Cheers..



  • 3.  Re: Full Gateway Migration

    Posted Oct 20, 2017 02:44 PM

    Thank you Ozan!

    Is there a way we can migrate all the content including the audits, system files, custom assertions everything with GMU from the Gateway using 9.1 to the Gateway 9.2 instead of upgrading the Gateway with the OOTB scripts?



  • 4.  Re: Full Gateway Migration

    Broadcom Employee
    Posted Oct 20, 2017 03:19 PM

    Samantha,

     

    The GMU is designed to move just system objects such as policies, services, storage configuration, encapsulated assertions, etc. It will not move underlying system files and audits. One solution to address audits/logs not needing to be moved is centralizing them through off box database for the audits and syslog for the logs.

     

    As for standing up new gateways on the latest version you may want to review using the headless capabilities of the gateway. This will allow for underlying system configuration to have a template along with auto creation of the REST and Gateway Management Service.

    Auto-Provision a Gateway Node - CA API Gateway - 9.2 - CA Technologies Documentation

    Auto-Provision a Gateway License - CA API Gateway - 9.2 - CA Technologies Documentation  

    Auto-Provision Internal Services - CA API Gateway - 9.2 - CA Technologies Documentation 

     

    Sincerely,

     

    Stephen Hughes

    Director, CA Support



  • 5.  Re: Full Gateway Migration

    Posted Oct 20, 2017 03:34 PM

    Thanks Stephen!

     

    We actually used the headless utility to create the Gateway. But we want to move all of our content from old v9.1 to v9.2 which includes OTK, API Portal configuration, custom assertions, audits, logs, private keys, passwords, certificates etc., so but doesn't seem like GMU will migrate the custom assertions or API Portal configuration (like the assertions "set as portal managed" etc., that comes with API Portal setup). Is there a way that can be done?



  • 6.  Re: Full Gateway Migration

    Broadcom Employee
    Posted Nov 07, 2017 01:23 PM

    Hello Samjon,

     

    Some components such as OTK/API Portal Configuration, Passwords, Private Keys, Certificates that all exist on Gateway and accessed via Policy Manager can be moved with GMU, given these items are used as dependencies in services (Portal configuration meaning portalman service/policy fragements for plans/etc).

     

    Do note that API Portal assertions, audits, logs, custom assertions, and un-referenced private keys/certificates in services, all will need to manually moved over to target boxes.