Page MenuHomePhabricator

[services][feature-flags] Dockerize the service
ClosedPublic

Authored by tomek on Feb 24 2023, 8:15 AM.
Tags
None
Referenced Files
Unknown Object (File)
Fri, Nov 8, 5:02 PM
Unknown Object (File)
Sun, Nov 3, 7:37 PM
Unknown Object (File)
Wed, Oct 30, 4:57 AM
Unknown Object (File)
Wed, Oct 30, 4:57 AM
Unknown Object (File)
Wed, Oct 30, 4:57 AM
Unknown Object (File)
Wed, Oct 30, 4:57 AM
Unknown Object (File)
Wed, Oct 30, 4:56 AM
Unknown Object (File)
Wed, Oct 30, 4:54 AM
Subscribers

Details

Summary

Introduce Docker config so that the service can be run in a container.

Depends on D6862

Test Plan

Run the container locally. Using Docker Desktop terminal send a GET to the service and check if it returns a response based on AWS DynamoDB content. Haven't figured out how to send a request from host, but verifying that is the next step.

Diff Detail

Repository
rCOMM Comm
Branch
flags
Lint
No Lint Coverage
Unit
No Test Coverage

Event Timeline

tomek requested review of this revision.Feb 24 2023, 8:31 AM
bartek added 1 blocking reviewer(s): jon.

Looks good to me, but letting @jon take a look


Haven't figured out how to send a request from host, but verifying that is the next step.

Not sure what you exactly mean, but docker-compose exposes the service port to host, so you should be able to simply

yarn run-feature-flags-service-in-sandbox
# in a separate terminal
curl "http://localhost:50055/features?platform=..." # etc

Looks fine to me.

The canonical way to handle args would be to use case for the positional arguments, then continue to consume the input with shift. But that would be more effort than just assuming we will have 1 or 2 arguments.

This revision is now accepted and ready to land.Feb 25 2023, 1:15 PM

Haven't figured out how to send a request from host, but verifying that is the next step.

Not sure what you exactly mean, but docker-compose exposes the service port to host, so you should be able to simply

yarn run-feature-flags-service-in-sandbox
# in a separate terminal
curl "http://localhost:50055/features?platform=..." # etc

That's exactly what I've done, but I have to figure out why it didn't work.

@jon could you explain a little bit what do you mean by

The canonical way to handle args would be to use case for the positional arguments, then continue to consume the input with shift. But that would be more effort than just assuming we will have 1 or 2 arguments.

Which part of the code does it correspond to?

Haven't figured out how to send a request from host, but verifying that is the next step.

Not sure what you exactly mean, but docker-compose exposes the service port to host, so you should be able to simply

yarn run-feature-flags-service-in-sandbox
# in a separate terminal
curl "http://localhost:50055/features?platform=..." # etc

The issue was caused by a fact that I was using localhost instead of 0.0.0.0. When running the service locally, there's no difference. But when a service is run within a container, the localhost doesn't work properly.

services/feature-flags/src/service.rs
29

We're currently using IPv4 only, because binding IPv6 address causes an error.
This shouldn't be an issue though, as for AWS deployment we're using IPv4 VPC. If we ever decide to change that, it should be possible to serve IPv4 only service to IPv6 network using some AWS solutions.
Solving the issue is tracked in https://linear.app/comm/issue/ENG-3212/support-ipv6-in-feature-flags-service