I'm moving a Jenkins from 'traditional' to JCasC.
We have a quite complex setup already, and I am wondering if there is a way to migrate somehow the current configuration without a need of going through settings and code it in .yaml?
btw. I'm not sure about installing JCasC plugin on prod to see the configuration... Am I wrong?
Thanks!
Make sure to have read the Getting Started and other docs.
Create new instance (you can do this onto your desktop/laptop) and copy over all the configuration, config.xml,*.xml, secrets and keys, but NO jobs into the new instance. See what to backup.
Add an entry to start in quiet mode by adding Jenkins.instance.doQuietDown()
You might want/need to change the url and port config too.depending on host. Mind you, you can do this all onto your desktop/laptop
Copy the plugins as well. Add the config as code plugin.
Startup the new instance, export the CasC config and review. The export is a starting point so fill in any missing gaps, etc. For example, since you did not copy jobs over, folders and views will not be created. Some plugin configs are.also not yet implemented.
Stop Jenkins, delete all the config (except the secret key). Put the JCasC config in place and start up. Compare the new configs to what you backed up/copied over. Repeat until they match. Now you should have a config that matches Prod.
Now you can install JCasc in Prod. The plugin does nothing until configured. But do a similar backup/compare of Prod config, before and after the config, just in case something changed in the intervening period
Of course, now you need to mke sure any changes are now only done via JCasC and not the UI, or you are out of sync again. See blog and JEP.
Related
How can I tell if the settings files associated with a Mosquitto instance, have been properly applied?
I want to add a configuration file to the conf.d folder to override some settings in the default file, but I do not know how to check they have been applied correctly once the Broker is running.
i.e. change persistence to false (without editing the standard file).
Test it.
You can run mosquitto with verbose output enabled, which will generally give you feedback on what options were set, but don't just believe that.
To do that, stop running Mosquitto as a service (how you do this depends on you setup) and manually run it from the shell with the -v option. Be sure to point it at the correct configuration file with the -c option.
That's not enough to be sure that it's actually working properly. To do that you need to test it.
Options have consequences or we wouldn't use them.
If you configure Mosquitto to listen on a specific port, test it by trying to connect to that port.
If you configure Mosquitto to require secure connections on a port, test it by trying to connect to the port unsecured (this shouldn't work) and secured (this should work).
You should be able to devise relatively simple tests for any options you can set in the configuration file. If you care if it's actually working, don't just take it on faith; test it.
For extra credit you can bundle the tests up into a script so that you can run an entire test suite easily in the future and test your Mosquitto installation anytime you make changes to it.
Having duplicate configuration options with different values is a REALLY bad idea.
The behaviour of mosquitto is not defined in this case, which value should be honoured, the first found, the last? When using the conf.d directory, what order will the files be loaded in?
Also will you always remember that you have changed the value in a conf.d file in the future when you go looking?
If you want to change one of the defaults in the /etc/mosquitto/mosquitto.conf file then edit that file. (Any sensible package management system will notice the file has been changed and ask what to do at the point of upgrade)
The conf.d/ directory is intended for adding extra listeners.
Also be aware that there really isn't a default configuration file, you must always specify a configuration file with the -c command line option. The file at /etc/mosquitto/mosquitto.conf just happens to be the config file that is passed when mosquitto is started as a service when installed using most Linux package managers. (The default Fedora install doesn't even setup the /etc/mosquitto/conf.d directory)
I have 2 .properties files for my project on hybris .
First one is used for CI process and as a result a got 4 zip files with my already built platform(after ant production).
On my prod instance i need to switch to another properties because there are all my connections to extended services such as mysql solr.. etc
How i can do that without running all ANT steps.
. ./setantenv.sh && sync && ant config -Denv=my_new_properties
then ./hybrisserver.sh start doesn't work.
There is no information on wiki https://cxwiki.sap.com/display/release5/ant+production+improvements
Check if Updating Configuration Settings at Runtime will be useful for you. You will need to use the FileBasedConfigLoader class and the runtime.config.file.path property.
Other best practices include using system variables for secure settings like DB URL. See "Using Environment Variables instead of Files for Secure Settings" section in Configuring the Behavior of SAP Commerce.
Another option you can look at is to have different config folders for different environments (e.g. config-dev, config-prd), and pass it to ant. e..g -Denv=config--dev
We want to have the same VSCode settings for the whole crew of developers. Also it would be fine to have a oneline command to tear VSCode down and restart it from scratch with predefined settings and plugins so that you do not have to worry about trying out plugins and getting beck to the known state. Kind of Config-as-Code for VSCode.
I already found:
https://code.visualstudio.com/docs/editor/extension-gallery#_command-line-extension-management
https://github.com/microsoft/vscode-dev-containers
https://marketplace.visualstudio.com/items?itemName=Shan.code-settings-sync&ssr=false#qna
https://github.com/gantsign/ansible-role-visual-studio-code-extensions
https://code.visualstudio.com/docs/remote/containers
https://github.com/gantsign/ansible-role-visual-studio-code
But non of these provides a good solution to me
We are using Mac and Windows machines and develop most of the time locally (not remotely in the cloud or the like).
I imagine like having a script like
.... projectname up
or
.... projectname reset
(or
.... projectname down)
to receive/reset the configured settings and newest plugins that have been configured for the project.
Have any ideas or use a similar solution already?
After doing a lot of research, playing with Docker, Ansible and so on... it seems that although I excluded it at first the plugin Settings Sync Plugin from Shan Khan is the way to go. It has round about 1 million installs!
Only dependency - you need a GitHub account to host your configs. That is what held me back at first - but it should be not that much of a problem to get one for everyone in the team and connect it to like a company-github-account.
Copy the files settings.json and keybindings.json to your target machine(s) to copy the settings. You can find those files here:
Win: ~\AppData\Roaming\Code\User
Mac: ~/Library/Application Support/Code/User/
Linux: ~/.config/Code/User
You can copy extentions from ~/.vscode/extensions or C:\Users\username\.vscode\extensions from linux/mac or windows respectively.
FalcoGer's answer should explain how to copy the files in a way VS Code will pick them up. If you only need to copy the config files once, this solution would be fine.
If you need to "sync" these config files on a regular basis, I would advise to create a Git repository where all config files will be stored.
When cloning the repo to local machines, you can symlink the files to the config destinations (see FalcoGer's anwser). Then when you need to "sync", you only have to run git pull and restart VS Code to apply the changes.
For your other script-related question, you could create a CLI for this. Python would be the most friendly way to do this. You can find an example here.
Not sure how to ask this question but would like to put it here and want to hear some suggestions.
So far, I use "DB_LINK" variable that has mongo database url in my config.json file. My Node app uses this variable to connect to the Mongo. But this DB_LINK also gets checked into git, which we dont want this to happen because we dont want to check in the passwords into git.
in my local development, I use local.json file that has all these configs and not check that file into git (in .gitignore entry). So it is fine making it work in my local dev environment, but the challenge is when Jenkins try to push the code to TEST, it has to pass testcases (it has to run test cases, so that time the DB_LINK value is needed) before deployment happens. so this is when I need this DB_LINK variable be passed from Jenkins.
Here is what I did so far ..
in Jenkins configurations, at the 'predefined parameters' I added DB_LINK=myMongoLink to parameters list.
but this value is not being handed over to my node app. Any suggestions on how to achieve what I am trying to achieve?
Ok. I figured this out. before the change, I used to pass a command from Jenkins to run my test cases like this
npm run test
but now,
DBLink=myDB npm run test
so the DBLink variable from here being handed over to the node app and was able to run the test cases. Before this change,
I used to pass this DBLink=myDB from a config file
Suppose I have a Grails application named myCoolApp.
Furthermore, suppose I have defined some basic properties in grails-app/conf/Config.groovy and grails-app/conf/DataSource.groovy under the test and production profiles.
Config.groovy is set to merge with the following .groovy external configuration file, if found at all:
grails.config.locations = ["file:${userHome}/.grails/${appName}-config.groovy"]
Finally, I have also defined, inside an external testing server, such a file, under a local *NIX user path:
/home/appServerTestUser/.grails/myCoolApp-config.groovy
Sadly, I find that for some reason, the external .groovy file's properties are not being merged when a Tomcat instance starts up.
What options do I have to make Grails tell me: "Oh, yes, I found your external config file at: /home/appServerTestUser/.grails/myCoolApp-config.groovy" and these are the properties I merged into Config.groovy?
Thanks!
File-based paths don't make much sense in a deployed app. It could work when deploying on your dev machine for testing, but will likely fail on any other machine. And it'll probably fail locally even if configured with the correct path since the process will like run as a different low-priviledge user.
You can use absolute paths, e.g. /etc/myapp/path/to/file, but this tends to couple deployment to filesystem structure, so if you develop in Windows and deploy on Linux it'd be tricky to get them both working.
So the best bet for Tomcat deployment is to use the classpath syntax. You can specify multiple files and it will load all that it finds, so I usually have one entry for local dev and one for the deployed app:
grails.config.locations = [
"classpath:${appName}-config.groovy",
"file:./${appName}-config.groovy"
]
I delete the entries for .properties files because Groovy syntax is so much more flexible, but use them if you like. I also keep the dev files in the project root (and exclude from source control).
So when deploying, name the file correctly (different apps will have different files, so no clashing there) and put them in Tomcat's lib directory. This is in the classpath, and so the classpath: entry will see it.