Now I know that consul-template can manage config file content when there's a change in k/v of consul, but what about create one? For example, a system has many users, and each user has his own config file, will consul-template able to create one config file for each user? If their config files share the same template.
consul-template can use a config source, for example consul-template.json:
...
template {
source = "/usr/local/app/etc/backends.cfg.ctmpl"
destination = "/usr/local/app/etc/backends.cfg"
command = "chown app_owner:app_group /usr/local/app/etc/backends.cfg && systemctl reload service"
}
template {
source = "/usr/local/app/etc/frontends.cfg.ctmpl"
destination = "/usr/local/app/etc/frontends.cfg"
command = "chown app_owner:app_group /usr/local/app/etc/frontends.cfg && systemctl reload service"
}
...
so you could create one consul-template config to manage the config of another consul template, at least in theory.
Related
Is it possible to add a virtual host programmatically to ejabberd, without manually editing ejabberd.cfg and restart the server?
I see there are many new features released in latest ejabberd 19.* Like rest APIs, is it plausible to dynamically add virtual via REST APIs.
I see there are many new features released in latest ejabberd 19.* Like rest APIs, is it plausible to dynamically add virtual via REST APIs.
I don't see any new command to execute to add a new host.
Is it possible to add a virtual host programmatically to ejabberd, without manually editing ejabberd.cfg and restart the server?
Well, you can edit configuration file programmatically. You probably will prefer to put the hosts option in another file. Example:
In ejabberd.yml
include_config_file: /etc/ejabberd/hosts.yml
# hosts
# - example.org
...
In the new file hosts.yml put:
hosts:
- example.org
And now you can add new hosts to that config file, and reload all it:
$ echo " - example.net" >> /etc/ejabberd/hosts.yml
$ ejabberdctl reload_config
I'm trying to check in my Hasura config.yaml file in a way that would be agnostic to my Hasura endpoint. The idea is that each developer will check out the project and work on a different Hasura instance, and then we would want to deploy and apply migrations separately to staging and production servers.
Is there, for instance, a way to make config.yaml get values from an .env file?
You can create a config.yaml.template file that contains the endpoints.
In this file you can define the endpoint like this:
endpoint: ${HASURA_ENDPOINT}
On startup of your hasura container you can generate a config.yaml file with envsubst:
envsubst '$HASURA_ENDPOINT' < /my_hasura_dir/config.yaml.template > /my_hasura_dir/config.yaml
You can use the —endpoint flag when executing commands. Similarly you can use flags for passing in admin secret and so on. Alternatively you can also use environment variables.
Read more here https://docs.hasura.io/1.0/graphql/manual/deployment/graphql-engine-flags/config-examples.html
i'm taking over a project from a client to add functionalities. I quite new in the development of Laravel 5.5
There are already 3 .env files in my project:
.env
.env.example
.env.live
.env.live is for production (APP/ENV=production) and runs on aws, the other 2 are for local use.
Now I have a new AWS EC2 server, database and so on and need a new env file to use these new instances. Let's say I create a new .env file called .env.dev
How how can I switch between the .env.dev and .env.live? Or how do I use this .env.dev?
If you're using Elastic Beanstalk, go to your environment, then click the Configuration menu item. From there click "Modify" in the "Software" section. A page will appear where you can add Environment Properties as key->value pairs.
You can then delete the .env files. These properties will be read by your Laravel app just like it reads the .env files.
You can also use the symbolic links
Just Delete .env from both of the server and create a symbolic link like.
ln -s .env.live .env // for live
ln -s .env.dev .env // for dev server
You can also keep this command inside your deployment script if you are using any CI/CD.
On every server you only need .env file to execute. If you have three files
.env
.env.live
.env.example
.env.other
you can create multiple files with .env.*. But when you will execute your application then your .env file will execute.
Now if you want to add new additional settings to your environment then you just need to add in .env file. and also specify all other .env.* files and change values according to server.
When you will deploy your application on live server. Then you just need to rename your .env.live file to .env and set configurations to that file.
cp .env.live .env
Note: if you already have .env file on your server(as you said your application is already on production server.) then you just need to add your environment settings to that file.
I'm having issue with referring the application/config file on a config server.
I already have a GAIA DEV Pool ready.
This is what I have done so far -
Created an application.yml file with required config property
hello-service:
message: Hello World From Spring Cloud Config Server
Checked it in git repo - feature/cs-hello branch.
Logged in to dev pool cf login -a [dev-pool-url]
Created the config server :
cf create-service -c "{\"git\": { \"label\": \"feature/cs-hello\", \"uri\": \""[GIT HTTPS URL]\", \"username\": \"[USERNAME]\", \"password\": \"[PASSWORD]\" } }" p-config-server standard config-server
Now, my referring [https://docs.pivotal.io/spring-cloud-services/1-4/common/config-server/configuring-with-git.html] - since my config file is not on the master branch, I used label.
Somehow my code is not finding the application file on config server.
Anyone here who can point me a direction?
Once you are done with config server creation, you need to bind that service with your application and you can need to provide following information in bootstrap.yml
spring:
application:
name: appName
There is a way to check either your config server is connecting to repository or not. Go to
PCF manager -->Services--> Config Server--> Manage
and then you should be able to see
Config server is online
I am using spring cloud config server to host a centralized location for all the property files configurations to be used in the project.
I tried using the config files from a local file system using below and it works fine:
spring.profiles.active=native
spring.cloud.config.server.native.searchLocations=file://${HOME}/Documents/test-config/cloud-config-properties/
I also used the git repo using: spring.cloud.config.server.git.uri=ssh://xxxxxx.com:7999/test/cloud-config-properties.git
I would like to try using a combination of this in my project.
Example - for dev/test profile - i would like to use from local filesystem and for the production - I would like to use Git repository.
I enabled both the git uri and native profiles in my application.properties in config server application. But the properties are always picked up from the local file system. Is this possible?
Not supported out of the box, however there is a workaround for this. You can define the basedir for the configuration server, which is where it saves the files it fetches from the remote server, by setting the property (in the config server):
spring.cloud.config.server.git.basedir=<your_dir>
If you are working with docker, you can map this directory to the host filesystem.
Now whatever file you put in there will be picked up by configuration-server if it matches any of the application/profile in the request. For example you could put a file there called application-dynamic.properties, and have all your clients use dynamic as the last profile, for example
spring.profiles.active=systesting,dynamic
This way everything you will put in application-dynamic.properties will override whatever is defined in your config repo.
One thing to notice though is that you need to add the file only after configuartion server starts, because it deletes this folder during startup.
Needles to say, it's not a good practice doing this in production (for example a restart will cause the file to be deleted), but for test/dev this is the best option.