wata727 / elastic_whenever Goto Github PK

Whenever supports syntax such as 1.day and 2.hours in schedule file.

Describe the following in README:

• Differences with whenever, supported options
• Mechanism of mapping with scheduled tasks

Current support policy

job_type

Not supported

set :job_templete

Not supported

env 'ENVIRONMENT_VARIABLE'

Not supported. Define environment variables in the task definition

every :reboot

Not supported

:roles options

Not supported

Running this command used to work for me in other rails app that i've deployed to ECS, in a new rails app i'm deploying it stopped working. In another rails I deployed about 2 months ago, it worked perfectly well. Is there an update that we don't know about?

One significant difference I noticed is that events list has been moved to the EventBridge console, does that affect anything?

Even though the command executes successfully, no event is being created. Any idea why?

bundle exec elastic_whenever -i 'scheduled-events' --verbose --version --launch_type FARGATE --cluster $CLUSTER_NAME --task-definition $TASK_DEFINITION_NAME --container $CONTAINER_NAME --region $AWS_REGION --access-key $AWS_ACCESS_KEY_ID --secret-key $AWS_SECRET_ACCESS_KEY --security-groups $SECURITY_GROUPS --subnets $SUBNETS

Problem:

We run elastic_whenever in an ECS Fargate container as part of a deploy process to schedule tasks. If you have a large number of scheduled tasks > 60, this can fail with the error message:

[fail] missing credential error occurred; please specify it with arguments, use shared credentials, or export `AWS_ACCESS_KEY_ID` and `AWS_SECRET_ACCESS_KEY` environment variable.

This error is misleading the root cause of the problem is that API calls for fetching credentials for the role assigned to the ECS task is rate limited to a burst of 60 per second and a steady rate of 40 per second.

The problem occurs when tasks are deleted before adding the tasks again. The deletion phase creates a new aws sdk client for each task to be deleted. Each client requests credentials thus hitting the API limit when the scheduled tasks grow to 60+.

Expected:

elastic_whenever should complete even when the scheduled task count is greater than 60. It should request credentials as infrequently as possible to prevent hitting AWS API limits.

#51 fixes this issue

Pre-Rails 3 apps and apps that don't use Bundler will redefine the rake and runner jobs respectively to function correctly.

Whenever supports any day of the week or symbol such as :weekend and :weekday.

every :sunday, :at => '12pm' do
  runner "Task.do_something_great"
end

https://docs.ruby-lang.org/en/2.4.0/Logger.html

A user can specify options to pass to chronic in whenever.

https://github.com/javan/whenever#parsing-dates-and-times

Elastic whenever uses the IAM role named ecsEventsRole. It has proper permissions when created by the system. (e.g. elastic whenever, management console, etc)
However, if a user creates it oneself, it may not has the appropriate permissions.

Even if specify a container name that does not exist in the task definition, no error occurs. Therefore, need to validate the container name.

Hi, thanks for the very nice gem.

I'd like to use the environment syntax on a configuration file instead of the @environment instance variable.

Because:

• Referring to instance variables feel weird to some people.
• It seems hard to find a relationship between a CLI option (e.g. --set 'environment=staging') and @environment in a configuration file.

So, I suggest as follow:

1. Can access to a new environment syntax:

-if @environment == 'production'
+if environment == 'production'
   every :day, at: '03:00am' do
     runner 'Hoge.run'
   end
 end

2. Add a new --environment CLI option (default: production) instead of --set 'environment=...'.

-elastic_whenever --set 'environment=staging'
+elastic_whenever --environment=staging

What do you think about this suggestion?
It would be great if you could consider this. Thanks.

😢