techscrolls.org

Diego Martín Nieto Cid

The AWS CLI or SDK can use several methods to get credentials that allows the EC2 instance where it's running to use resources, like S3 buckets. One of which is the Instance Metadata Services (IMDS). Currently, the last version is `v2,` the main difference being that v2 requires a token to be requested before other endpoints may be called.

For instance, lets ask for a token from the IMDSv2 that is valid for 5 minutes:

```shell
    TOKEN=$(curl -X PUT "http://169.254.169.254/latest/api/token" \
                 -H "X-aws-ec2-metadata-token-ttl-seconds: 300")
```

This `PUT` call allows the caller to get the token that will be used in other endpoint calls.

Now, to assume the role of the EC2 instance and get temporary credentials like the secret access key and  the access key, the following call, provided with the `TOKEN` value, shall be executed:

```shell
    curl -X GET "http://169.254.169.254/latest/meta-data/iam/security-credentials/${AWS_ROLE_NAME}" \
         -H "X-aws-ec2-metadata-token: $TOKEN"

    {
      AccessKeyId: '...',
      SecretAccessKey: '...',
      Token: '...'
    }
```

One thing to keep in mind is that these endpoints have a default hop limit of one, meaning it will only work directly from the EC2 instance and not from a docker container, for instance. When the `curl` commands are executed from the docker instance it must hop one time to the EC2 instance running the container and then another time to the IMDS server and, as the hop limit is one, the request will be rejected.

This behaviour is particularly troublesome when our application is running in Elastic Beanstalk with the ECS multi-container docker platform. To circumvent the hop limit, a file can be placed in the `.ebextensions` folder which gets executed when building the environment. Let's say it's called `.ebextensions/hop-limit.config`, the file must have the following content:

```shell
    files:
      "/tmp/set-hop-limit.sh":
        mode: "000755"
        content: |
          #!/bin/bash
          TOKEN=$(curl -s -X PUT -H 'X-aws-ec2-metadata-token-ttl-seconds:60' 'http://169.254.169.254/latest/api/token')
          INSTANCE_ID=$(curl -s -H "X-aws-ec2-metadata-token:$TOKEN" 'http://169.254.169.254/latest/meta-data/instance-id')
          aws ec2 modify-instance-metadata-options --region us-west-2 --instance-id "$INSTANCE_ID" --http-put-response-hop-limit 2 --http-endpoint enabled

    commands:
      0_set-hop-limit:
        command: /bin/bash -x /tmp/set-hop-limit.sh || true
```

This script uses the aws CLI tool to modify the instance metadata options of the EC2 instance to allow a hop limit of up to two hops. It also uses the IMDSv2 server to get the instance ID before calling the aws CLI command.

One last thing to note is that the role of the EC2 instance must have the right permissions to be able to modify the instance metadata options. So, head to the IAM section of the Amazon console and modify the EBS role to add the `EC2ModifyInstanceMetadataOptions` permission.


In AWS, one often needs to access certain resources, like S3 or SQS, from an EC2 instance. There are several methods to get the credentials to access those resources one of which is the Instance MetaData Service.

Assuming an IAM role using the Instance MetaData Service

The `node_modules` folder contains, most of the time, the project dependencies that it needs to work. The `src` folder is then used to hold the source code of the application which oftentimes is compiled down to a compatible ECMAScript version into `dist` or `build` folders.

When the source folder contains the sub-modules of the application, references to them start to spring in the form of relative paths with a series of `..` before the actual module. This relative paths become unmanageable rather quickly as they are not tolerant to directory restructuring.

To solve this problem some bundlers support the concept of `aliases` which allow a symbol to be used as a kind of absolute reference relative to the configured base directory. Another strategy is to define `NODE_PATH` to be the project's `src` directory.

The strategy explored in this article takes advantage of the way  modules are resolved by `nodejs`, that is check the path to the current directory in reverse order.

By creating a `node_modules` directory inside the project's `src` other files may use the sub-modules without any prefix, just as project dependencies are referenced. **In essence, an application `node_modules` folder**.

Let's review how the directory structure of such a project could look like:

```
  project-root
  ├── node_modules
  ├── package.json
  └── src
      ├── node_modules
      │    └── project-name
      │        ├── module-a
      │        └── module-b
      └── index.js
```

The `project-name` folder creates a namespace of modules that helps avoiding conflicts with released packages which would be installed inside the `node_modules` under `project-root`.

With this project setup `index.js` or other files under the `src` folder may reference sub-modules in a very natural way:

```
const a = require('project-name/module-a')
```


An *application* node_modules directory may be used to effectively remove relative paths in source files when referencing to the application sub-modules.

Project and application `node_modules`

Querying a JSON resource (created by `gatsby-transformer-json`) requires knowledge of the fields that are part of the resource. For instance, a resource may define a localised text message like below.

```
{
  "text": {
    "en": "...",
    "es": "...",
    ...
  }
}
```

A page using this resource needs to know exactly which languages are available to include them in the page query.

The [`gatsby-transformer-rawjson`](https://github.com/diegonc/gatsby-transformer-rawjson) plugin allows to publish top-level properties of a JSON node in raw form using the JSON GraphQL scalar type.

Once the plugin is added to the `gatsby-config.js` file, and assuming the above snippet is available in a MessagesJson resource, the raw item may be accessed using the following query:

```
{
  allMessagesJson {
    childRawMessageJson {
      text
    }
  }
}
```

Without specifying any particular language, the page will get every translation available for the property `text`.

- - -

DISCLAIMER: currently the plugin has a very narrow set of features:

* It will pick JSON nodes only if the are named `*Json`
* It will not allow to filter the properties to be exported as a scalar. All top-level properties are exposed except for `id`, `parent`, `children` and `internal`.


The gatsby-transformer-rawjson plugin allows to publish the properties of a JSON node in raw form using the JSON GraphQL scalar type.

Raw JSON query on Gatsby

Calling `wrapAsync` on a function will not propagate the value of `this` from the resulting function to the wrapped function. But the behaviour may be emulated by transforming it into an actual parameter.

The emulation procedure involves transforming `this` into a parameter, then calling `wrapAsync` and finally moving the parameter back to the function context. The mentioned process can be achieved with the following composing of functions:

```
compose(
  thisToParam,
  Meteor.wrapAsync,
  paramToThis
);
```
There are a couple of complementary functions to define before the composing function may be used, namely `thisToParam` and `paramToThis`. The respective implementations are shown below.

```
function thisToParam(targetFn) {
  return function (...args) {
    return targetFn(this, ...args);
  };
}
```

```
function paramToThis(targetFn) {
  return function (_this, ...args) {
    return targetFn.apply(_this, args);
  };
}
```


Calling `wrapAsync` on a function will not propagate the value of `this` from the resulting function to the wrapped function. But the behaviour may be emulated by transforming it into an actual parameter.

Meteor wrapAsync and this

The Meteor object provided by the framework has a property named `settings` which is populated from the file `settings.json`, specified on the command-line when the server is started. There are two main sub-keys:

* `private`: server-only namespace
* `public`: key-space published to the client

It's worth noting that the settings may be modified at run-time, during server bootstrap. Most notably, those modifications affecting the `public` key-space **will be pushed to the client**, allowing to compute properties at run-time.

One plausible use-case is the forwarding of environment variables from the server to the client.

Worth mentioning is the fact that Meteor keeps a reference to the public hashmap from which it publish values to the client. For that reason replacing the full object like below won't work.

```
Meteor.settings.public = {SETTING_ONE: '1'}
```

What one needs to do instead is use `Object.assign` to modify the object instance inplace.

```
Object.assign(
  Meteor.settings.public,
  {SETTING_ONE: '1'}
)
```


Meteor settings in the public key-space may be computed at run-time during server bootstrap and pushed to the client.

techscrolls.org

Assuming an IAM role using the Instance MetaData Service

Project and application `node_modules`

Raw JSON query on Gatsby

Meteor wrapAsync and this

Meteor Settings on the Client-Side