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
Usage:
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
Usage:
ey-core logs -e <env-name> -c <account-name> -s <server-name>
-
ey-core recipes
This would run chef specific commands within an environment
Usage:
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.
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
Comments
Article is closed for comments.