zodern / mup-aws-beanstalk

Deploy Meteor apps to AWS Elastic Beanstalk using Meteor Up
127 stars 56 forks source link

Deploy runs into timeout and reports error #177

Open derwaldgeist opened 1 year ago

derwaldgeist commented 1 year ago

When doing my first deploy, it took ages in the "Waiting for Beanstalk environment to finish terminated" stage, and finally I got this error message:

  Finishing upload. This could take a couple minutes
=> Creating version
=> Configuring Beanstalk environment
 Created Environment
=> Waiting for Beanstalk environment to finish launching
=> Waiting for Beanstalk environment to finish terminated

/Users/tom/.nvm/versions/node/v17.4.0/lib/node_modules/mup-aws-beanstalk/lib/env-ready.js:83
      const value = result.Environments[0][prop];
                                          ^

TypeError: Cannot read properties of undefined (reading 'Status')
    at Timeout.check [as _onTimeout] (/Users/tom/.nvm/versions/node/v17.4.0/lib/node_modules/mup-aws-beanstalk/lib/env-ready.js:83:43)
    at runMicrotasks (<anonymous>)
    at processTicksAndRejections (node:internal/process/task_queues:96:5)

Afterwards, I ended up in the Node console.

(I am using Node 17, because my regular Node 12 environment I had been using before threw an error message right away. But it might have been #175 which I later resolved by omitting us-east-1.)

derwaldgeist commented 1 year ago

This is my config:

// Configuration file for https://github.com/zodern/meteor-up
const credentials = require('../../credentials-deployment');

module.exports = {
  servers: {
    one: {
      host: 'redis.marblever.se',
      username: 'ubuntu',
      pem: '~/.ssh/marble-aws-us-east1.pem'
    }
  },

  app: {
    type: 'aws-beanstalk',
    name: 'marble-staging',
    path: '../../',
    // region: 'us-east-1',
    auth: {
      id: credentials.staging.beanstalkIAM.auth.id,
      secret: credentials.staging.beanstalkIAM.auth.secret
    },
    minInstances: 1,
    maxInstances: 3,
    instanceType: 't2.small',
    sslDomains: ['staging.marblever.se', 'staging.marblear.com', 'staging.marble-ar.com'],
    forceSSL: true,

    env: {
      ROOT_URL: 'https://staging.marblever.se',
      MONGO_URL: credentials.staging.mongo.MONGO_URL,
      MONGO_OPLOG_URL: credentials.staging.mongo.MONGO_OPLOG_URL
    }

  },

  plugins: ['mup-redis', 'mup-aws-beanstalk'],
  redis: {
    // Server to run redis on.
    servers: { one: {} },
    // Version of redis. Add '-alpine' to use a much smaller docker image
    version: '3.2.10-alpine'
  }
};
derwaldgeist commented 1 year ago

In the Beanstalk events section, I see this error:

image

derwaldgeist commented 1 year ago

With Node 12, I'm getting this error:

  Finishing upload. This could take a couple minutes
=> Creating version
=> Configuring Beanstalk environment
 Created Environment
=> Waiting for Beanstalk environment to finish launching
=> Waiting for Beanstalk environment to finish terminated

(node:14935) UnhandledPromiseRejectionWarning: TypeError: Cannot read property 'Status' of undefined
    at Timeout.check [as _onTimeout] (/Users/tom/.nvm/versions/node/v12.18.2/lib/node_modules/mup-aws-beanstalk/lib/env-ready.js:83:43)
    at runMicrotasks (<anonymous>)
    at processTicksAndRejections (internal/process/task_queues.js:97:5)
(node:14935) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag `--unhandled-rejections=strict` (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 1)
(node:14935) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.
applew commented 1 year ago

I experienced something similar but was able to successfully deploy the app in the Elastic Beanstalk console. I clicked into the Application versions area and deployed the uploaded version. All went well.

This was the error I received:

TypeError: Cannot read properties of undefined (reading 'EventDate')
    at getLastEvent (/usr/local/lib/node_modules/mup-aws-beanstalk/lib/env-ready.js:27:20)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
    at async checker (/usr/local/lib/node_modules/mup-aws-beanstalk/lib/env-ready.js:61:21)
    at async waitForEnvReady (/usr/local/lib/node_modules/mup-aws-beanstalk/lib/env-ready.js:115:3)
    at async Object.deploy [as handler] (/usr/local/lib/node_modules/mup-aws-beanstalk/lib/command-handlers.js:206:3)
    at async PluginAPI.runCommand (/usr/local/lib/node_modules/mup/lib/plugin-api.js:135:9)
cunneen commented 1 year ago

@derwaldgeist did you solve this?

I suspect you need to set :

module.exports = {
  // ...
  app: {
    // ...
    longEnvVars: true, 
  },
};
cormip commented 1 year ago

A bit more to this issue that I also ran into. When I enabled longEnvVars: true, I started getting a new error:

=> Creating version
=> Configuring Beanstalk environment
=> Deploying new version
NoSuchKey: The specified key does not exist.
    at Request.extractError (C:\Users\me\AppData\Roaming\nvm\v14.21.2\node_modules\mup-aws-beanstalk\node_modules\aws-sdk\lib\services\s3.js:711:35)

I think it's related to #175 requiring region to be omitted, but region being expected for this method call?

Trimming out spaces from my env allowed it to shrink enough not to need longEnvVars: true

cunneen commented 1 year ago

@cormip sorry this probably won't help with the issue, but this might be helpful for others so I'll drop this in here for (future?) reference. For what it's worth, yesterday I was able to do two new EB deployments and an update of an existing EB deployment, with:

But my 2 deployments that used longEnvVars also have app.region explicitly specified as ap-southeast-2; while the other ( us-east-1 ) deployment was a very basic one without an explicit region or longEnvVars. But they all succeeded. So if nothing else, my experience yesterday reinforces your theory discussed in #175 .

My mup.js looks like this:

module.exports = {
  app: {
    type: "aws-beanstalk",
    name: "beanstalkapp",
    path: "../",
    auth: {
      // IAM user's Access key ID
      id: "**redacted-accesskey-id**",
      // IAM user's Secret access key
      secret: "**redacted-secret-access-key**",
    },
    env: {
      ROOT_URL: "https://**redacted**.com",
      MONGO_URL:
        "mongodb+srv://**redacted-username**:**redacted-pass**@**redacted-mongo-SRV**/**redacted-db**?retryWrites=true&w=majority",
      MONGO_OPLOG_URL:
        "mongodb+srv://**redacted-oplog-username**:**redacted-pass**@**redacted-mongo-SRV**/local?authSource=admin",
      NODE_ENV: "production",
      MAIL_URL:
        "smtps://**redacted-username**:**redacted-pass**@smtp.mailgun.org:465/",
      TOOL_NODE_FLAGS: "--max-old-space-size=4096"
    },
    envName: "beanstalkenv-mup-env-20230704",

    minInstances: 3,
    maxInstances: 6,

    instanceType: "m5d.large",

    forceSSL: true,
    region: "ap-southeast-2",
    gracefulShutdown: true,
    longEnvVars: true,

    oldVersions: 3,
    buildOptions: {
      server: "https://**redacted**.com",
      serverOnly: true,
    },
    customBeanstalkConfig: [
      {
        namespace: "aws:autoscaling:asg",
        option: "Cooldown",
        value: "300",
      },
      {
        namespace: "aws:elasticbeanstalk:command",
        option: "DeploymentPolicy",
        value: "AllAtOnce",
      },
      {
        namespace: "aws:autoscaling:launchconfiguration",
        option: "EC2KeyName",
        value: "my-ssh-key.pem",
      },
    ],
  },
  plugins: ["mup-aws-beanstalk"],
};
tcastelli commented 10 months ago

I experienced something similar but was able to successfully deploy the app in the Elastic Beanstalk console. I clicked into the Application versions area and deployed the uploaded version. All went well.

This was the error I received:

TypeError: Cannot read properties of undefined (reading 'EventDate')
    at getLastEvent (/usr/local/lib/node_modules/mup-aws-beanstalk/lib/env-ready.js:27:20)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
    at async checker (/usr/local/lib/node_modules/mup-aws-beanstalk/lib/env-ready.js:61:21)
    at async waitForEnvReady (/usr/local/lib/node_modules/mup-aws-beanstalk/lib/env-ready.js:115:3)
    at async Object.deploy [as handler] (/usr/local/lib/node_modules/mup-aws-beanstalk/lib/command-handlers.js:206:3)
    at async PluginAPI.runCommand (/usr/local/lib/node_modules/mup/lib/plugin-api.js:135:9)

Did you get any solution to this issue?

It's annoying having to deploy manually from EB all the times

    at getLastEvent (/home/runner/work/obit/obit/.deploy/common/node_modules/mup-aws-beanstalk/lib/env-ready.js:27:20)
    at runMicrotasks (<anonymous>)
    at processTicksAndRejections (internal/process/task_queues.js:95:5)
    at async checker (/home/runner/work/obit/obit/.deploy/common/node_modules/mup-aws-beanstalk/lib/env-ready.js:61:21)
    at async waitForEnvReady (/home/runner/work/obit/obit/.deploy/common/node_modules/mup-aws-beanstalk/lib/env-ready.js:115:3)
    at async Object.deploy [as handler] (/home/runner/work/obit/obit/.deploy/common/node_modules/mup-aws-beanstalk/lib/command-handlers.js:206:3)
    at async PluginAPI.runCommand (/home/runner/work/obit/obit/.deploy/common/node_modules/mup/lib/plugin-api.js:135:9)
    at async PluginAPI._runHooks (/home/runner/work/obit/obit/.deploy/common/node_modules/mup/lib/plugin-api.js:78:13)
    at async PluginAPI._runPostHooks (/home/runner/work/obit/obit/.deploy/common/node_modules/mup/lib/plugin-api.js:113:9)
    at async PluginAPI.runCommand (/home/runner/work/obit/obit/.deploy/common/node_modules/mup/lib/plugin-api.js:140:7)
paulincai commented 10 months ago

@tcastelli what MUP version and mup-aws-beanstalk do you use?

tcastelli commented 10 months ago

@tcastelli what MUP version and mup-aws-beanstalk do you use?

Sorry forgot to reply, as seen in #182 our issue was related to something else!