How to setup environment variable for symfony.
Like if i run my project than it should detetched the envirment and do the action, as an example ---
http: //production.com -> prod * environment *
http: //localhost:9200 -> * dev * environment --- for elasticsearch
http: //localhost:8000 -> * dev * environment --- for doctrine/mysql
So if i run a mysql request on localhost it should make the request at
http: //localhost:8000
and if i make a request for elasticsearch it should make the request at
http: //localhost:9200
and if it runs in the production environment it should do the request at
http: //production.com:9200 --- elasticsearch
http: //production.com:8000 --- doctrine/mysql
I think it can be done at parameters.yml but i really did not get how it can be done.
Can someone help me to solve this problem.
Thanks a lot in advanced .
I'm not exactly sure what's the problem here so I'll give you a more general answer.
Symfony has a really great way to configure your project for different situations (or environments). You should have a look at the official documentation which explains things in depth.
By default, Symfony comes with 3 configurations for different environments:
app/config/config_dev.yml for development
app/config/config_prod.yml for production
app/config/config_test.yml for (unit) testing
Each of these config files can override settings from the base configuration file which is app/config/config.yml. You would store your general/common settings there. Whenever you need to override something for a specific environment, you just go to the environment config and change it.
Lets say you have the following base configuration in app/config/config.yml:
# Doctrine Configuration
doctrine:
dbal:
driver: pdo_mysql
host: "%prod_database_host%"
port: "%prod_database_port%"
dbname: "%prod_database_name%"
user: "%prod_database_user%"
password: "%prod_database_password%"
charset: UTF8
Now lets say, you have 3 different databases for each environment - prod, dev and test. The way to do this is to override the configuration in the environment configuration file (lets say app/config/config_dev.yml:
# Doctrine Configuration
doctrine:
dbal:
driver: pdo_mysql
host: "%dev_database_host%"
port: "%dev_database_port%"
dbname: "%dev_database_name%"
user: "%dev_database_user%"
password: "%dev_database_password%"
charset: UTF8
Add the necessary %dev_*% parameters to your app/config/parameters.yml.dist and app/config/parameters.yml. Now, whenever you open your application using the dev environment, it will connect to the specified database in your parameters (%dev_database...%).
This is pretty much it. You can do the same for any configuration you need to be changed in a specific environment. You should definitely have a look at the documentation. It's explained straight-forward with examples.
Related
It is really getting hard to understand and debug the rules for ingress. Can anyone share a good reference?
The question is how the ingress works without specifying the host?
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/force-ssl-redirect: \"false\"
name: my-app
spec:
rules:
http:
paths:
- backend:
path: /
serviceName: my-app
servicePort: http
Upon assigning a host (e.g.- host: aws-dsn-name.org) it doesn't work.
Upon changing the path to path: /v1/ it also doesn't work :( .
How can I debug/check whether the mapping is correctly done?
Additionally, when to use extensions/v1beta1 or networking.k8s.io/v1beta1
There is pretty good documentation available here for getting started. It may not cover all aspects but it does answer your questions. Ingress controller is basically a reverse proxy and follows similar ideas.
The snippet you have shared is called single backend or single service ingress. / Path would be default. It's the only entry so every request on the exposed port will be served by the tied service.
Host entry; host: aws-dns-name.org should work as long as your DNS is resolving aws-dns-name.org to the IP of a node in the cluster or the LB fronting the cluster. Do a ping to that DNS entry and see if it's resolving to the target IP correctly. Try curl -H 'Host: aws-dns-name.org' IP_Address to verify if ingress responding correctly. NGINX is using Host header to decide which backend service to use. If you are sending traffic to IP with a different Host entry, it will not connect to the right service and will serve default-backend.
If you are doing path based routing, which can be combined with host based routing as well, NGINX will route to the correct backend service based on the intercepted path. However, just like any other reverse proxy, it will send the request to the specified path (http://service:80/v1/). Your application may not be listening on /v1/ path so you will end up with a 404. Use the rewrite-target annotation to let NGINX know that you serving at /.
API resources versions do switch around in K8s and can be hard to keep up with. The correct annotation now is networking.k8s.io/v1beta1 (networking.k8s.io/v1 starting 1.19) even though the old version is working but eventually will stop working. I have seen cluster upgrades break applications because somebody forgot to update the API version.
I deploy a laravel project on google cloud app engine everting is working fine expect 'pictures' that am fetching from products table in MySQL database.
The images are broken, all the thing are working fine on the localhost.
Here's my app.yaml:
runtime: php73
handlers:
- url: /assets
static_dir: public/assets
- url: /(.+\.(gif|png|jpg))$
static_files: public/uploads
upload: .+\.(gif|png|jpg)$
runtime_config:
document_root: public
env_variables:
## Put production environment variables here.
APP_KEY: Already Get this from .env
APP_STORAGE: /tmp
VIEW_COMPILED_PATH: /tmp
SESSION_DRIVER: cookie
CACHE_DRIVER: database
## Set these environment variables according to your CloudSQL configuration.
DB_DATABASE: ufurnitures
DB_USERNAME: ufurnitures
DB_PASSWORD: Already set the pass
DB_SOCKET: /cloudsql/ufurniture:us-central1:ufurnitures
## To use Stackdriver logging in your Laravel application, copy
## "app/Logging/CreateStackdriverLogger.php" and "config/logging.php"
## into your Laravel application. Then uncomment the following line:
# LOG_CHANNEL: stackdriver
beta_settings:
# for Cloud SQL, set this value to the Cloud SQL connection name,
# e.g. "project:region:cloudsql-instance"
cloud_sql_instances: ufurniture:us-central1:ufurnitures
I have an 'uploads' folder in a public directory where pictures are getting saved.
Just change this:
- url: /(.+\.(gif|png|jpg))$
static_files: public/uploads
upload: .+\.(gif|png|jpg)$
To this!
- url: /uploads
static_dir: public/uploads
And hurry it worked! ^_^
We ported our Rails 5.2 app to Heroku and were able to get almost everything working with FlyingSphinx.
Search and indexing work well but as a convenience to our users, we try to let them know when the daemon is down for service or if we're re-indexing.
Previously, we were able to use
ThinkingSphinx::Configuration.instance.controller.running?
But this always returns false on Heroku even if the daemon is running.
Our thinking_sphinx.yml doesn't specify file locations or information on where the pid is, so I suspect this may be the issue; however, I can't find anywhere that would explain what to use in thinking_sphinx.yml for Heroku/FlyingSphinx, if it's at all necessary https://freelancing-gods.com/thinking-sphinx/v3/advanced_config.html.
Our thinking_sphinx.yml looks like this now:
common: &common
mem_limit: 40M
64bit_timestamps: true
development:
<<: *common
test:
<<: *common
mysql41: 9307
quiet_deltas: true
staging:
<<: *common
quiet_deltas: true
production:
<<: *common
version: '2.2.11'
quiet_deltas: true
Suggestions?
Ah, I've not had this requested before, but it's definitely possible:
require "flying_sphinx/commands" if ENV["FLYING_SPHINX_IDENTIFIER"]
ThinkingSphinx::Commander.call(
:running,
ThinkingSphinx::Configuration.instance,
{}
)
When this is called locally, it'll check the daemon via the pid file, but when it's called on a Heroku app using Flying Sphinx, it talks to the Flying Sphinx API to get the running state. Hence, it's important to only run the require call for Heroku-hosted environments - there's no point having local/test envs calling the Flying Sphinx API.
Setting file/pid locations in Heroku/Flying Sphinx environments are mostly not going to do anything, because Flying Sphinx overwrites these anyway to match the standardised approach on their servers. The exceptions are for stopfiles/exceptions/etc, and those corresponding files are uploaded to Flying Sphinx so the daemon there can be configured appropriately.
I am trying to set up a brand new Ghost blog on a Centos 7 server. I have Nginx, Node and Ghost installed and have written all of the necessary configuration files. It's pretty close to working, but I wanted to use MySQL instead of SQLite, so I created a new (blank) MySQL database called "ghost_db", set up a MySQL user called "ghost", gave the user permission for the database, and added these lines to config.js:
database: {
client: 'mysql',
connection: {
host: 'localhost',
user: 'ghost',
password: 'mypassword',
database: 'ghost_db'
charset: 'utf8'
filename: path.join(__dirname, '/content/data/ghost-dev.db')
},
debug: false
}, ...
When I try to start it, I get an error that suggests I use knex-migrator to initialize the database.
[john#a ghost]$ npm start
> ghost#1.18.4 start /var/www/ghost
> node index
[2017-12-10 00:08:00] ERROR
NAME: DatabaseIsNotOkError
CODE: MIGRATION_TABLE_IS_MISSING
MESSAGE: Please run knex-migrator init ...
However, some comments on Stackexchange suggest that using knex-migrate may be unnecessary for this version of Ghost, and when I run knex-migrator, it also fails:
[john#a ghost]$ knex-migrator init
[2017-12-09 16:21:33] ERROR
NAME: RollbackError
CODE: SQLITE_ERROR
MESSAGE: delete from "migrations" where "name" = '2-create-fixtures.js' and "version" = 'init' and "currentVersion" = '1.18' - SQLITE_ERROR: no such table: migrations
...[omitted]
Error: SQLITE_ERROR: no such table: migrations
I think the problem may be that the "ghost_db" database I initially created is blank. The "ghost-dev.db" file that is pointed to in the config.js seems to be for SQLite, but I get the same error message if I switch config.js back to using an SQLite database. I don't know what the "migrations" table is. I found the schema that I think Ghost expects at [https://github.com/TryGhost/Ghost/blob/1.16.2/core/server/data/schema/schema.js], but I'm not sure how to use that to initialize the tables, etc., except for doing it very laboriously by hand. I'm stumped!
Knex-migrator is new in Ghost 1.0, which also uses a config.<env>.json file for configuration.
It sounds like you added your database config into a file called config.js which was correct <1.0, however it seems you were installing Ghost 1.0 and therefore your new connection details would have needed to live in config.production.json.
You are correct that Ghost-CLI isn't intended for use on CentOS (it's for Ubuntu), but I'd be very surprised if it failed to install Ghost correctly. The issues with other OSs are mainly in the subtle differences between systemd i.e. keeping Ghost running.
The answer for me was just to not create the database at all and let Ghost do it as part of ghost install.
I took an alternate approach which proved successful, which was to install Ghost as an NPM module. The official Ghost instructions label this as an "advanced" process, but it wasn't too difficult to follow the instructions in the excellent nehalist.io and Stickleback blogs. There was also some useful guidance on the HugeServer knowledgebase. I think ultimately the problem was that the Ghost commandline interface (ghost-cli) wasn't designed for Centos 7.
I added MySQL, and PHPMyAdmin cartridges to my openshift php app.
After mysql cartridge was added I saw the page which says:
Connection URL: mysql://$OPENSHIFT_MYSQL_DB_HOST:$OPENSHIFT_MYSQL_DB_PORT/
but I have no idea what does it mean.
When I access mysql database through PHPMyAdmin,
I see 127.8.111.1 as db host, so I configured my symfony 2 app (parameters.yml):
parameters:
database_driver: pdo_mysql
database_host: 127.8.111.1
database_port: 3306
database_name: <some_database>
database_user: admin
database_password: <some_password>
Now when I access my web page it throws an error, which I believe related to mysql connection. Can someone show me proper way of doing the above?
EDIT: It seems mysql connection works fine, but somehow
Error 101 (net::ERR_CONNECTION_RESET): Unknown error
is thrown.
The code I use and works very well to make my apps working both on localhost and openshift without changing database config parameters every time I move between them is this:
<?php
# app/config/params.php
if (getEnv("OPENSHIFT_APP_NAME")!='') {
$container->setParameter('database_host', getEnv("OPENSHIFT_MYSQL_DB_HOST"));
$container->setParameter('database_port', getEnv("OPENSHIFT_MYSQL_DB_PORT"));
$container->setParameter('database_name', getEnv("OPENSHIFT_APP_NAME"));
$container->setParameter('database_user', getEnv("OPENSHIFT_MYSQL_DB_USERNAME"));
$container->setParameter('database_password', getEnv("OPENSHIFT_MYSQL_DB_PASSWORD"));
}?>
This will tell the app that if is openshift environment it needs to load different username, host, database, etc.
Then you have to import this file (params.php) from your app/config/config.yml file:
imports:
- { resource: parameters.yml }
- { resource: security.yml }
- { resource: params.php }
...
And that's it. You will never have to touch this file or parameters.yml when you move on openshift or localhost.
Connection URL: mysql://$OPENSHIFT_MYSQL_DB_HOST:$OPENSHIFT_MYSQL_DB_PORT/
OpenShift exposes environment variables to your application containing the host and port information for your database. You should reference these environment variables in your configuration instead of hard-coding values. I am not a Symfony expert, but it looks to me like you would need to do the following in order to use this information in your app:
Create a pre-start hook for your application and export variables in Symfony's expected format. Add the following to the .openshift/action_hooks/pre_start_php-5.3 file in your application's git repo:
export SYMFONY__DATABASE__HOST=$OPENSHIFT_MYSQL_DB_HOST
export SYMFONY__DATABASE__PORT=$OPENSHIFT_MYSQL_DB_PORT
Symphony uses this pattern to identify external configuration in the environment, and will make the this configuration available for use in your YAML configuration:
parameters:
database_driver: pdo_mysql
database_host: "%database.host%"
database_port: "%database.port%"
EDIT:
Another option to expose this information for use in the YAML configuration is to import a php file in your app/config/config.yml:
imports:
- { resource: parameters.php }
In app/config/parameters.php:
$container->setParameter('database.host', getEnv("OPENSHIFT_MYSQL_DB_HOST"));
$container->setParameter('database.port', getEnv("OPENSHIFT_MYSQL_DB_PORT"));