Import, then deploy all proxies in a directory.

Not applicable

I need to import and then deploy a number of API proxies at once. Should I use the deploy_all.sh scrip from the Apigee sample proxies repo, or should i modify the apigee-deploy-grunt-plugin?

Solved Solved
1 13 434
1 ACCEPTED SOLUTION

Here ya go, @Jason Brown. See if this works for you.

This will import, and then deploy, all proxies found in a given directory.

Example usage:

./importThenDeployAllProxiesFromDirectory.sh -o nordstrom-eval1 -e test -s ~/dev/nordstrom/testdir -n -v

It should work whether the api proxies are zip files, or are exploded directories.

importthendeployallproxiesfromdirectorysh.zip

View solution in original post

13 REPLIES 13

It's up to you. Remember that when deploying a proxy, you need to specify the proxy name, the environment, and the revision of the proxy.

If you want to deploy all proxies that are already present in an organization, writing a quick purpose-built bash script to do this wouldn't be difficult.

  1. inquire proxies
  2. foreach proxy:
    1. inquire latest revision (guessing?)
    2. deploy

See attached for an example.

deployallsh.zip

Dino - thanks; I have the tool working well. I had expected it to deploy all proxies (possibly zipped) from a given folder, but instead it deploys all proxies on Edge. We have many proxies, because we're building a proxy for each resource, so that we could bundle the certain resources into customizable products. Do you also have an already-built-script for deploying not just a proxy in an "apiproxy" folder, but many proxies?

Ah, got it. No, I don't have a script like that lying around. But I can assemble one from pieces I have lying around in "the lab". I'm at lunch - will get to it after, and will update here.

So ... you wan to deploy all either from an "exploded" directory OR a bundled zip? Or do you prefer one or the other?

I'm imagining

sourcedir/
sourcedir/proxy1/
sourcedir/proxy1/apiproxy
sourcedir/proxy1/apiproxy/policies/... 
sourcedir/proxy1/apiproxy/targets/... 
sourcedir/proxy1/apiproxy/resources/... 

sourcedir/proxy2/
sourcedir/proxy2/apiproxy
sourcedir/proxy2/apiproxy/policies/... 

is that what you're thinking?

hi Dino, yes, that is what we're thinking that I could eventually hand off to our Operations team. I was envisioning an exploded directory. I'm working on a script as well. thanks

I attached one below.... have you seen it? tried it?

Dino - yes, tried it, worked really well and had nice user messages. My mgr was more comfortable handing off a Grunt task mgr script to our DevOps team than a bash script, so we're going down that route. thank you.

oh! good, glad you're able to solve it. Maybe it helped a little.

@jasonbrown It sounds as if you use Apigee Grunt along with Dino's script for this? just want to learn how you leverage these tools.

Not applicable

Based on my experience. It depends on the type of APIs you're building, and your goals with those APIs are @Jason Brown. So I'd categorize deployments as PoCs (Proof Of Concept) or Production-Grade.

  • PoC: If you want a quick solution that gets your API Proxies deployed to Edge, I find Maven, Grunt or most build tools overkill. In this case, the script provided by Dino or apigeetool alone are good enough. After all, you just want to get those APIs deployed quickly without too much scaffolding. However, there's a caveat. Sometimes, when these tiny or experimental projects grow and if you started with a build tool from the beginning, you'd have saved some of you and your team's setting this app with some of the benefits mentioned below.
  • Production-Grade: For this type of deployments, your goals might be different than a PoC. By different, I mean you want your deployments to follow Continuous Integration/Deployment principles. More specifically, automating execution of code coverage and reviews, unit, and functional testing, configuration management, publishing OpenAPI and SmartDocs to Developer Portal or a CMS, etc. IMO, you need a build tool that does more than bash scripts as scripts can quickly run out of control.

These essentially are my two guidelines for deciding whether or not it's worth using a build tool or scripts.

Diego, ultimately we need production-grade but we're at PoC phase currently. We have many proxies, because we're building a proxy for each resource, so that we could bundle the certain resources into customizable products. How should I modify the Grunt tool to build and deploy not just the proxy in the "apiproxy" folder, but many proxies at once?

In your case, if you implement one API Proxy per resource, you'll have a file structure as this one:

.
├── API-Proxy-Resource-A
│   ├── apiproxy (*)
│   ├── grunt (*)
│   └── Gruntfile.js(*)
├── API-Proxy-Resource-B
  *
API-Proxy-Resource-C
└── ├── *

... you can have as many API Proxy Resources as you want<br>

In this case writing a bash script that cd into each folder and run Grunt command should be pretty straightforward:

$ cd API-Proxy-Resource-A
$ grunt --env=test --username=... --password=...
$ cd API-Proxy-Resource-B
$ grunt --env=test --username=... --password=...
$ cd API-Proxy-Resource-...
$ grunt --env=test --username=... --password=...

Maybe store a list of API-Proxy-Resources in an array and iterate overeach element.

Hope it helps!

Here ya go, @Jason Brown. See if this works for you.

This will import, and then deploy, all proxies found in a given directory.

Example usage:

./importThenDeployAllProxiesFromDirectory.sh -o nordstrom-eval1 -e test -s ~/dev/nordstrom/testdir -n -v

It should work whether the api proxies are zip files, or are exploded directories.

importthendeployallproxiesfromdirectorysh.zip

@Jason Brown .

You might also be interested in ApigeeDM (Apigee Deploy Multiple) - Node.JS based command line tool. You can find more information here & here.