I'm deploying a Symfony 2.8 application to Elastic Beanstalk and the DB parameters are read from ENV. The EB already has the RDS env set, like RDS_HOSTNAME, RDS_DB_NAME etc, but Symfony needs to read these parameters from env variables prefixed with SYMFONY__. Is there a way to map existing RDS_ variables to the SYMFONY__ ones? I tried with an env.config file placed in the .ebextensions dir, with the following content (sample):
option_settings:
- namespace: aws:elasticbeanstalk:application:environment
option_name: SYMFONY__ENV__DATABASE__HOST
value: "$RDS_HOSTNAME"
I know I could duplicate the values in the env.config, but I rather not.
Thanks!
You could try Fn::GetOptionSetting:
option_settings:
- namespace: aws:elasticbeanstalk:application:environment
option_name: SYMFONY__ENV__DATABASE__HOST
value:
"Fn::GetOptionSetting":
Namespace: "aws:elasticbeanstalk:application:environment"
OptionName: "RDS_HOSTNAME"
DefaultValue: ""
https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/ebextensions-functions.html#ebextensions-functions-getoptionsetting
Related
I'm attempting to provide an environment variable in a config YAML file as such:
resources:
be_warehouse:
config:
conn_str:
env: DB_CONN_STR
analytics_warehouse:
config:
conn_str:
env: WH_DB_CONN_STR
but I am receiving the following error:
Invalid scalar at path root:resources:analytics_warehouse:config:conn_str. Value "{'env': 'WH_DB_CONN_STR'}" of type "<class 'dict'>" is not valid for expected type "String".
I have seen this syntax used in this official example. Am I missing something obvious?
The env: ENV_VAR support is available for config schema which is typed as StringSource. If these are #resources you are creating you just need to declare config_schema={'conn_str': StringSource} instead of just using str.
https://docs.dagster.io/_apidocs/config#dagster.StringSource
I would like to exclude fields when exposing my API from my user class that extends FOSUser.
I've setup JMS Serializer on the global config file and created a FOSUB config to only expose the fields I need.
Global Config:
app/config/config.yml
jms_serializer:
metadata:
directories:
FOSUB:
namespace_prefix: "FOS\\UserBundle"
path: "#AppBundle/Resources/config/serializer/fos"
FOS config file:
src/AppBundle/Resources/config/serializer/fos/Model.user.yml
FOS\UserBundle\Model\User:
exclusion_policy: ALL
properties:
id:
expose: true
email:
expose: true
roles:
expose: true
This config is working perfectly on my local machine however it doesn't work when deployed on prod. Both use same stack, my guess is that on prod somehow the serializer can't find FOS config file.
Any help would be much appreciated.
The issue was somehow related to the naming of the config file.
While in local (macos) the file name Model.user.yml was working, in production (centos) it didn't work. So I had to rename the file to Model.User.yml then it worked fine on both.
I tried to find some documentation related to this issue but couldn't find any.
Take away: Make sure that the config file name represent exactly the entity you want to override.
I would like to store all Salt files (pillars, states, data files, etc.) in a git repository, so that this repository can be cloned on several different deployments.
Then I would like to be able to change the value of some pillar settings, such as a pathname, or a password, but without editing the original file which is in version control (i.e. those modifications would be local only and not necessarily versioned).
I would like to be able to pull new versions from the original repository (e.g. to add new pillar and state definitions) without losing the customized values.
E.g. the "base" or "default" pillar file would have settings like:
service:
dir: /var/opt/myservice
username: myuser
password: mypassword
and I would like to customize some settings, in another file, without changing the base file:
service:
dir: /mnt/data/myservice
password: secret_password
The modified settings should take precedence over the base / default ones.
Is it possible to do this by using environments (e.g. a "base" environment and a "custom" environment)?
Or perhaps by including these custom pillar files?
The documentation seems to indicate that there isn't a fixed order for overriding pillar settings.
Let me first suggest a way where you keep the original file and the customized settings in the git repository. See below how to override setting with a file outside of git.
Setup Git Pillar
I assume all files are stored in a git pillar like described here. I am using the syntax of salt version 2015.8 here.
ext_pillar:
- git:
- master https://gitserver/git-pillar.git:
- env: base
In your top.sls file you can list different SLS files. They will override each other in the order listed in the top file:
# top.sls
base:
'*':
standard
'*qa'
qaservers
'hostqa':
hostqaconfig
This will apply on all servers:
# standard.sls
test:
setting1: A
setting2: B
This will apply on all servers with the name ending with 'qa':
# qaservers.sls
test:
setting2: B2
This will apply to the server with the name 'hostqa':
# hostqa.sls:
test:
setting1: A2
The commands salt hostqa saltutil.refresh_pillar and salt hostqa pillar.data will then show that the values A2 and B2 as they have all been merged together.
As this works without specifying environments, I suggest not to use environments here.
Override some local settings outside of Git
To override some of your settings locally, you can add another external pillar. One of the most simple ones is cmd_yaml that will run a command (here: cat) and merge the output with the current pillar:
ext_pillar:
- git:
- master https://gitserver/git-pillar.git:
- env: base
- cmd_yaml: cat /srv/salt/local_override.sls
All external pillars are executed in the order listed in the configuration file.
I'm new to Saltstack and I'm just trying to do some simple installs on a subset of minions. I want to include Environments so I have my file roots as:
file_roots:
base:
- /srv/salt/base
dev:
- /srv/salt/dev
qa:
- /srv/salt/qa
stage:
- /srv/salt/stage
prod:
- /srv/salt/prod
I set up the git backend:
fileserver_backend:
- git
- roots
I'm using gitfs set as:
gitfs_remotes:
- https://github.com/saltstack-formulas/postgres-formula
- https://github.com/saltstack-formulas/apache-formula
- https://github.com/saltstack-formulas/memcached-formula
- https://github.com/saltstack-formulas/redis-formula
So I have the master set up and I add top.sls to /srv/salt/stage with
include:
- apache
stage:
'stage01*':
- apache
But I get an error when I execute
salt -l debug \* state.highstate test=True
Error
stage01.example.net:
Data failed to compile:
----------
No matching sls found for 'apache' in env 'stage'
I've tried many ways and the master just can't seem to find the apache formula I configured for it.
I found the answer and it was sitting in the Saltstack docs the whole time.
First you will need to fork the current repository such as postgres-formula.
Depending on the environment create a branch of the same name in your newly create fork of the repo.
So for example I wanted to use postgres in my stage environment. So it wouldn't work until I created a branch named stage ined my forked repo of postgres-formula then it worked like a charm.
How can I change the default migration dirctory in the config.yml?
Right now I am using 2 bundles with different db-connections and I would like to create migrations files and store them in different directories to use the doctrine:migrations:migrate --em=whatever function in depency of the bundle.
For example:
doctrine:migrate:diff --em=whatever #creating a version file in the DoctrineMigrationsWhatever directory
php app/console doctrine:migrations:status --em=whatever # shows only the version files, that belong to the bundle
If you'll create separate entity manager for this second connection/bundle you will get another directory in your DoctrineMigrations dir. For example:
app/
DoctrineMigrations/
entityManager1/
entityManager2/
If you want put all migrations to another directory, you can set it inside your config.yml:
doctrine_migrations:
dir_name: '%kernel.root_dir%/../Acme/CommonBundle/DoctrineMigrations'
namespace: 'Acme\CommonBundle\DoctrineMigrations'
If you want some more complex thing like put migrations from em1 to dir1 inside bundle1 and put migrations from em2 to dir2 inside bundle2 you will need an additional two configuration files where you'll specify dirs for particular bundles:
http://docs.doctrine-project.org/projects/doctrine-migrations/en/latest/reference/introduction.html#configuration
And then you run your migrations like this:
doctrine:migrations:status --em=em1 --configuration=./path/to/bundle1/Resources/config/migrations.yml
doctrine:migrations:status --em=em2 --configuration=./path/to/bundle2/Resources/config/migrations.yml
By https://github.com/doctrine/DoctrineMigrationsBundle/pull/46
the migrations.yml file should look like:
name: Doctrine Postgres Migrations
migrations_namespace: Application\Migrations
table_name: migration_versions
migrations_directory: PostgreSqlMigrations
For other people who found this page and spent hours trying to implement Cyprian's solution, it doesn't work.
First, --configuration gets clobbered, and second, the doctrine migrations bundle doesn't support multiple entity managers.
See https://github.com/doctrine/DoctrineMigrationsBundle/issues/18 for information about --configuration and see https://github.com/doctrine/DoctrineMigrationsBundle/pull/46 for an open pull request to support multiple entity managers.
If and when PR #46 goes through, this will be a trivial configuration:
doctrine_migrations:
default:
dir_name: ...
namespace: ...
em2:
dir_name: ...
namespace: ...
The only tweaks available right now, are:
doctrine_migrations:
dir_name: '%kernel.root_dir%/../Acme/CommonBundle/DoctrineMigrations'
namespace: 'Acme\CommonBundle\DoctrineMigrations'
But that will update the configuration for all migrations across all entity managers.
For Symfony 4, the recommended approach is to use %kernel.project_dir% instead, and put it in the src/ folder namespaced by App\:
doctrine_migrations:
dir_name: '%kernel.project_dir%/src/DoctrineMigrations'
namespace: 'App\DoctrineMigrations'