cloudyr/aws.ec2metadata

Access to EC2 Instance Metadata

aws.ec2metadata's Issues

Implement package

Write functions to return metadata described here: http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html

Then import this package into aws.signature to implement to IAM role functionality of cloudyr/aws.signature#11

is_ec2 / get_instance_metadata results in 10 second delay on mac

I was tracking down why the aws.s3 library was slow to make an initial request, but quick to perform subsequent requests. I traced the delay back to this psuedo call stack:

aws.s3::head_object
aws.s3::s3HTTP
aws.signature:::locate_credentials
ec2metadata:::is_ec2
aws.ec2metadata:::get_instance_metadata
curl::curl_fetch_memory("http://169.254.169.254")

Running the curl call directly on a mac produces:

> curl::curl_fetch_memory("http://169.254.169.254")
Error in curl::curl_fetch_memory("http://169.254.169.254") : 
  Timeout was reached: Connection timed out after 10001 milliseconds

Since when NOT on ec2 it can't connect to the IP, it times out with a default timeout of 10 seconds. It seems the curl library must be caching the "host unavailable" message for approximately 15 seconds on my system, but I can't find a parameter to control this.

Is it expected that the is_ec2 function produces a 10 second delay when not running on ec2

As a hacky workaround on my system, I just override the is_ec2 function after loading the library, but this obviously won't work as an improvement to this package.:

assignInNamespace("is_ec2", function ( ...) { FALSE }, "aws.ec2metadata") 

Potential solutions that this package could implement:

• Manually cache the result of is_ec2 or get_instance_metadata. This will produce a 10 second delay only once, instead of every call to this function. This would especially be useful for a "no" result.
• Manually lower the timeout on curl to a lower value
• Perform some faster check to see if the ip / base url is listening on port 80, rather than relying on a timeout at all.

IMDSv2 support

Please specify whether your issue is about:

• a possible bug
• a question about package functionality
• a suggested code or documentation change, improvement to the code, or feature request

IMDS v2 requires that a token be requested prior to getting metadata. This should be a fairly simple fix - issue the token request prior to curling for the metadata. Thoughts?

Seeking new maintainer!

This package is not being actively maintained. If you're interested in contributing or taking over, please express your interest here.

Reading object in s3 bucket from ecs fargate task

Please specify whether your issue is about:

• a possible bug
• a question about package functionality
• a suggested code or documentation change, improvement to the code, or feature request

I have a shiny app running on an ecs fargate task using the rocker:shiny-verse base docker image. I can't read an s3 file
within the initialisation of the shiny app (global.R file). Interestingly it does work when I change the method of serving the app in the docker file.

The docker command that works is:

CMD ["R", "-e", "shiny::runApp('/srv/shiny-server/my_app', 3838, host='0.0.0.0')"]

And the method I want to use but doesn't work:

CMD ["/usr/bin/shiny-server.sh"]

What is the intended method of accessing the permissions granted to the IAM role, how can I read from the s3 bucket within an ecs fargate task?

My global.R file looks like this:

## load package
library(ini)
library("aws.ec2metadata")

Sys.setenv("AWS_DEFAULT_REGION" = "eu-west-2")
if (is_ecs() == T) {
   metadata$iam_role("ecsTaskExecutionRole")
}

config = aws.s3::s3read_using(read.ini,
                              object = 'my_object.ini',
                              bucket = 'my_bucket')

I can't get the session Info of the Fargate task or any logs but know it's the s3 connection that is failing as removing the
s3_read_using() call allows the app to run as expected. I have also double checked that the ecsTaskExecutionRole has s3 read
permissions required. The bucket also definitely exists and as does the object and it's in the correct region (eu-west-2).

ECS testing is broken

When I wrote the patch for this, it was broken and can't correctly test that an R script is running on ECS.