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.
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 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.
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
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.
From this you can start an interactive console
This would return the current user information
This would deploy your application
ey-core deploy -a <app-name> -e <environment-name> -c <account-name>
This would retrieve a list of Engine Yard environment variables for environments that you have access to.
This would retrieve a list of Engine Yard environments that you have access to.
This is to retrieve API token from Engine Yard Cloud
This would remove your Engine Yard API token
This would retrieve the latest configuration logs for an environment
ey-core logs -e <env-name> -c <account-name> -s <server-name>
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>
This would open an SSH session to the environment's application master
This would show the deployment status of the app
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,
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. defaults: 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) - SOME_LARGE_DIR 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