import eoapi-cdk constructs and reuse them

[emileten]

Another take at #135. This one is much simpler. All modifications are in infrastructure/aws, and are all about swapping direct native AWS CDK calls with eoapi-cdk construct calls.

There is no change in behavior in this PR ; i.e, the deployed infrastructure should be identical for a given set of environment variables after this PR is merged.

The code in this branch synthesized successfully and I'm trying to deploy right now.

[emileten]

One significant difference with the other PR, in addition, is that I'm not adding the ingestor & browser, I'd like to keep things simple and do that later in another PR if possible.

[emileten]

Looks like it mostly works, here are links of services vector, stac, raster.

There is just some formatting left to be done and then we should try to deploy to the existing staging and see if anything gets broken.

[vincentsarago]

One significant difference with the other PR, in addition, is that I'm not adding the ingestor & browser, I'd like to keep things simple and do that later in another PR if possible.

🙏 yeah we def want stac-browser and ingestor to be deployed but 👍 for doing it later :-)

[emileten]

@vincentsarago this is ready to be merged. Important notes :

• I deployed this to a stack named eoapi-dev in the devseed account. I swapped the domain mappings : *.eoapi.dev point to APIs in this stack (I copied the content of the DB over).
• removed the NAT gateway (and made corresponding necessary networking changes we discussed on slack).
• added the STAC ingestor. I created a custom domain name for this with a record at ingestor.eoapi.dev, for now it's not working but we might need to wait -- otherwise it's available at the non custom URL that's shown in the stack.
• added the STAC browser, see this public endpoint : http://eoapi-dev-stac-browser.s3-website-us-east-1.amazonaws.com.

[emileten]

When you're 👍 I can merge and later delete the eoapi-staging stack.

[emileten]

Edit : ingestor.eoapi.dev works now

[vincentsarago]

@emileten I'm getting an error at https://ingestor.eoapi.dev/docs is that expected?

[emileten]

@vincentsarago
Yes the /docs is broken in the custom domain name, there is a ticket for this in eoAPI-cdk. I'll try to fix that tomorrow.

You can reach /docs with the api gateway url though (not on my computer right now, but that url is one of the outputs of the stack).

[emileten]

@vincentsarago

🤔 can we avoid setting a default to our stack here?

☝️ done

the /docs is broken

☝️ fixed https://ingestor.eoapi.dev/docs with developmentseed/eoapi-cdk#82

[vincentsarago]

@emileten can you explain again the relationship between the custom domain name and the GitHub tag?

[emileten]

sorry, the way I wrote it, it's confusing.

In eoSTACSettings, I defined two parameters for the purpose of the STAC browser :

• the catalog URL, which I named stac_api_custom_domain_name, that the browser is going to show
• the version of the browser, stac_browser_github_tag

These two things should probably go in another configuration class named eoStacBrowserSettings for clarity.

And the assertion just checks that a version is provided if a catalog url is provided to avoid unclear errors downstream.

Does that make sense @vincentsarago ?

[vincentsarago]

👍 thanks

These two things should probably go in another configuration class named eoStacBrowserSettings for clarity.

That would be lovely