ey-core usage in Engine Yard Cloud

The gem `ey-core` comes as a successor for the `ey` (engineyard) gem which had been used in previous deployments. In turn more technically `ey-core` could be identified as a wrapper for the `engineyard` gem.


Differences in between `ey` and `ey-core` gems

ey-core does have all the features that could be included with ey gem.

As stated previously, `ey-core` is the successor of `ey` gem.  The `ey-core` gem acts as a wrapper for `ey` gem as per now due to maintenance compatibility. 

There are a few key differences in between the 2 gems and there are alternative ways to handle them.

  • ey rollback

You won't have ey rollback in `ey-core`, but as an alternative, you can always consider redeploying to the latest known working reference, to bring your application back with the known changes.

`ey-core deploy -e <env-name> -a <app-name> -c <acc-name> -f <git-reference>`

  • ey init

ey init is no more. This creates the `ey.yml` file within the application's config directory and makes the ey command to use it while deploying. In ey-core, you cannot initialize ey.yml, instead you can add ey.yml within the config directory manually.

  • ey rebuild

This is missing from ey-core and was utilized to fix configuration issues on servers. In ey-core you can do the same via the dashboard.

`ey-core` specific documentation

  • ey-core accounts

You can retrieve a list of Engine Yard accounts that you have access to.

  • ey-core applications

You can retrieve a list of Engine Yard applications that you have access to.

  • ey-core console

From this you can start an interactive console

  • ey-core whoami

This would return the current user information

  • ey-core deploy 

This would deploy your application


ey-core deploy -a <app-name> -e <environment-name> -c <account-name>
  • ey-core environment_variables 

This would retrieve a list of Engine Yard environment variables for environments that you have access to.

  • ey-core environments

This would retrieve a list of Engine Yard environments that you have access to.

  • ey-core login

This is to retrieve API token from Engine Yard Cloud

  • ey-core logout

This would remove your Engine Yard API token

  • ey-core logs 

This would retrieve the latest configuration logs for an environment


ey-core logs -e <env-name> -c <account-name> -s <server-name>
  • ey-core recipes

This would run chef specific commands within an environment


For downloading recipes from an environment.

ey-core recipes download -e <env-name> -c <account-name>

To upload the recipes to an environment

ey-core recipes upload -e <env-name> -c <account-name>
  • ey-core ssh

This would open an SSH session to the environment's application master

  • ey-core status

This would show the deployment status of the app

  • ey-core timeout-deploy

This would mark a stuck deployment as failed

Using `ey.yml` with `ey-core`


Many of the clients have a common problem as on how `ey.yml` could be utilized with `ey-core` or rather if it could be utilized with such. The simple answer would be yes.

The initial engineyard gem (ey gem) did have the ey.yml generation scenario and capability to add and customize the deployments based on that. For an example if it's required to precompile the assests for your application you can consider specifying,

precompile_assets: true

within ey.yml 's `default:` section.

Therefore you need to add your customized `ey.yml` file to the config directory of your app for the customization.

Therefore you can customize the attributes specified below according to your needs.

# 'defaults' applies to all environments running this application.
# Only set these options if needed. The defaults are correct for most applications.
  bundler: detect                           # By default, bundler is detected via Gemfile. Options: true: always run bundler; false: never run bundler
  composer: detect                          # By default, composer is detected via composer.lock. Options: true: always run composer; false: never run composer
  npm: detect                               # By default, npm is detected via package.json. Options: true: always run npm; false: never run npm
  bundle_without: GROUP1 GROUP2             # exclude groups on bundle install (default: test development)
  bundle_options: --OPTION                  # extra bundle install options (--local, --quiet, etc; does not override bundle_without)
  copy_exclude:                             # don't rsync the following dirs (some people like to skip .git)
  keep_releases: 3                          # number of releases to keep in /data/APP_NAME/releases. Older releases are removed. Default: 3
  keep_failed_releases: 3                   # number of failed releases to keep in /data/APP_NAME/failed_releases. Older releases are removed. Default: 3
maintenance_on_restart: false # show maintenance page during app restart (default: false except for glassfish and mongrel) maintenance_on_migrate: true # show maintenance page during migrations (default: true) precompile_assets: true # enables rails assets precompilation (default: inferred using app/assets and config/application.rb) precomplie_assets_task: assets:precompile # override the assets:precompile rake task precompile_unchanged_assets: false # if true, does not check git for changes before precompiling assets. asset_dependencies: # a list of relative paths to search for asset changes during each deploy. - app/assets # default - lib/assets # default - vendor/assets # default - Gemfile.lock # default - config/routes.rb # default - config/application.rb # default - config/requirejs.yml # custom option (be sure to include defaults if you specify this option) asset_strategy: shifting # choose an alternet asset management strategy. See rails_assets/strategy.rb for more info. asset_roles: :all # specify on which roles to compile assets (default: [:app, :app_master, :solo]) ignore_database_adapter_warning: true # hide database adapter warning if you don't use MySQL or PostgreSQL (default: false) # Environment specific options apply only to a single environment and override settings in defaults. environments: env_production: precompile_unchanged_assets: true # precompiles assets even if no changes would be detected (does not check for changes at all). asset_strategy: shifting # choose an alternet asset management strategy (shifting, cleaning, private, shared) asset_roles: :all # specify on which roles to compile assets (default: [:app, :app_master, :solo] - must be an Array) env_staging asset_strategy: private # Use an asset management that always refreshes, so staging enviroments don't get conflicts


1. https://github.com/engineyard/core-client-rb

2. https://github.com/engineyard/engineyard


Article is closed for comments.