Is it possible to extract the websphere application server configuration from one server and import it into another?
I realise there's a Configuration Archive file, however that option is only available from within RATIONAL developer tool.
I have standalone websphere server instances, e.g. these servers are not defined within RATIONAL developer tools; which i need to export ALL their configuration settings to allow me to:-
a). Compare all configuration settings to ensure two instances have exactly the same config.
b). Allow me to export configuration from one server and import into another so that i know both are configured exactly the same.
The Configuration Archive functionality isn't restricted just to RAD.
You can do this via wsadmin scripting as well. See here: http://www-01.ibm.com/support/knowledgecenter/SSAW57_8.5.5/com.ibm.websphere.nd.doc/ae/rxml_atconfigarchive.html?lang=en
Related
First let me give some background
We have our own VPS, so we do not wish to use Azure to host our web applications.
We have already successfully created a CI/CD pipeline to our VPS by installing an agent on it for a .NET Core project.
We use Azure DevOps (formerly known as VSTS) to host our code in GIT and handle our backlogs and CI/CD pipelines.
We have several .NET Framework projects where we use XTD transforms to transform our web.config files on delivery/deployment to have the correct connection strings and other configuration properties.
This makes it possible to pull the master branch from our remote repo and have it working in seconds on a previously unused (for this application) development environment without the need for any configuration.
Now to get to my question
The master branch of the .NET Core project for which we already have the CI/CD pipeline in place holds the configuration in the json files for the staging environment it is continuously delivered to. When a developer pull the master branch, he/she first needs to configure these to suite the local debug environment.
This is an undesirable situation for us.
How can we make it so that if we use .NET Core we can use a mechanism that will allow us to have the project work on a local debug environment without any configuration and in the CI/CD pipeline?
What have we already tried?
we have found that we can have multiple versions of the appsettings.json file for the different environments like appsettings.debug.json and than in the static method CreateWebhost of the Program class we can call on or the other. But how we can automate this is something that we haven't been able to figure out or find documentation about.
Okay, so here are some options you can take advantage of TODAY. (there are im sure more options/approaches)
Option A
Configure the master branch to have appsetting.development.json with connection string to DEV database( or lowest environment)
remove any connection string from appsettings.json
Merge master accordingly.
Create environment variables on each of the backend servers for the connection string; ex, system environment variable named ConnectionStrings:cartDB with connection string to the database for the environment for which the backend server used.
The result of this will be that when running using DEVELOPMENT as the environment variable, then it will be able to connect to database everyone can access.
However, since all OTHER web servers have environment variables with connection string, they will take highest level of precedence, and will therefore be the values set when calling something such as
string connectionString = Configuration.GetConnectionString("cartDB");
This will satisfy the requirements you mentioned above.
Option B:
Configure the master branch to have appsetting.development.json with connection string to DEV database( or lowest environment)
remove any connection string from appsettings.json
Place appsetting.staging.json, appsettings.prod.json in source control, and set environment name variable in web servers. :/ not the best of options/advised against.
(its worth mentioning since I have seen this happen, we all have)
Option C
Add appsetting.staging.json, appsettings.prod.json to source control and use a token in place of the connection string value. Then, leverage some type of Tokenization Task to replace those tokens with the appropriate values.
I am new to OpenShift so apologies in advance if this question is not very clear.
I have a project starting in Openshift and will use the Elasticsearch provided docker image as a data store.
ElasiticSearch is bound only to local host by default when installed, and if I was running app on a server I would keep this configuration so as not to expose ElasticSearch interface as connectivity only required by the application, no need to expose outside of project.
If I make a route for Elasticsearch without changing it's default config, it is accessible to other Pods in project but also outside of the project, like the main application. Is it possible to make a route that is internal to the project only so that Elasticsearch interface is not accessible outside of the project or by other means ? Or a way to have a common local host address between pods/applications ?
I tried to group the services but still not available.
Any support to put me in right direction really appreciated.
Currently we are maintaining all our properties in the database and applications are referenced through their Spring Profile Name , now we are transitioning into Cloud Foundry, keeping this in focus how can we build Spring Cloud Config Server using existing database to read application properties, so far in the documentation i see reference to Git Repository
http://cloud.spring.io/spring-cloud-config/spring-cloud-config.html#_spring_cloud_config_server
Not currently, we are limited to git and svn. There is a pull request for mongodb for an example though.
No longer true, now support is available for jdbc http://cloud.spring.io/spring-cloud-config/single/spring-cloud-config.html#_jdbc_backend
Is there a way to configure the generated SSIS deployment wizard (manifest) to only allow for SQL Server deployment? Basically I'm looking to eliminate this screen, or disable the file system deployment option.
It is possible to build a small app which is based on the SSIS API and implement only the SQL Server deployment type. For un example, you can check this http://www.selectsifiso.net/?p=510
I am using Intellij IDEA to develop my applications and I use glassfish for my applications.
When I want to run/debug my application I can configure it from Glassfish Server -> Local and define arguments at there. However there is another section instead of Glassfish Server, there is a Remote section for configuration. I can easily configure and debug my application just defining host and port variables.
So my question is why to need for Glassfish Server Local configuration(except for when defining extra parameters) and what is difference between them(I mean performance or etc.)?
There are a number of development work-flow optimizations and automation that can be performed by an IDE when it is working with a local server. I don't have a strong background in IDEA, so I am not sure which of the following they may have implemented:
using in-place|exploded|directory deployment can eliminate jar/war/ear creation in the IDE and deconstruction in the server. This can be a significant time saver.
linked to 1 is smarter redeployment. In some cases, a file change (like changing a jsp or an html file) does not need to trigger redeployment.
JDBC driver integration allows users to configure their IDE to access a DB and then propagates that configuration (which usually includes driver jars, etc.) into the server's classpath as part of deployment of an app.
access to server log files during deployment and execution.
The ability to start and stop the server... even today, you do need to restart GlassFish sometimes.
view the generated Java sources of a JSP.
Most of these features are not available with a remote server and that has a negative effect on iterative development since the break between edit and validate can be fairly long.
This answer is based on my familiarity with the work that we have done for the NetBeans/GlassFish integration. The guys at IntelliJ are smart, so I would not be surprised if they have other features that are available when you are working with a local server.
Local starts Glassfish for you and performs the deployment. With Remote you start Glassfish manually. Remote can be used to debug apps running on another machines, Local is useful for development and testing.