Until now I stored ARNs for different environments in config files, now I want to resolve the ARNs dynamically at runtime, but I'm not able to find any "best practices" for this.
The resources are managed with AWS CDK so I have multiple options to store/retrieve the ARNs at runtime:
create and query Parameter Store entries
create and query Stack outputs for each resource
query the resources of the Stack
query the resources by using the SDK for specific services
What would you recommend?
Regards,
Patrick
Since my application needs access to the parameter store anyway, I decided to store the ARNs there.
Related
Our Change Approval team is trying to get us to use Octopus to deploy SSIS packages to our Production environment. The problem is that the tool (Azure DevOps) we use to generate the build for Octopus doesn't create or populate Project parameters when it deploys a project. It does, however, create and populate Environment parameters.
Up to now we have not used Environment parameters at all because we don't use multiple environments on any one server.
The CA team is suggesting that we work around the inability to deploy Project parameters by converting them to Environment parameters, and create one Environment per project.
This feels wrong to me, but I haven't been able to come up with a reason we can't do this, nor have I found one anywhere on the internet so far. On the other hand, I also haven't found anybody saying that they are doing this and it's working fine, either.
So, does anybody have any arguments for or against using Environment parameters to replace Project parameters per se?
Assume that I don't have to worry about any possible future need for multiple environments on a server.
I know this sounds crazy, but I had a thought and I was willing to try it out. I use GitLab pages for all my online projects, but a lot of them are ASP.NET MVC, which is an issue as I don't think you can run ASP.NET MVC sites on GitLab pages. I then thought, what if I make a site using something like angular or node.js, and have a central API for all my web projects? I thought that was a great idea, until I realized I couldn't use a database either. I guess what I'm asking is, would it be possible to create a REST API that uses JSON files for storage and node.js as the request pages, to create an API without a database?
Of course.
If you think about a database from the perspective of your application code, it is basically just a place to store and retrieve data.
Imagine the database library you are using has two simple methods, store and retrieve. In your application code, you could write db.store('here is the item') and the later on, db.retrieve().
However, those store and retrieve methods could be implemented in many different ways to provide the same effective behavior from the perspective of your application. Some examples:
Send/query the data to/from an external data store, such as PostgreSQL
Write it to a file on disk and read it back later
Store the data in memory
Make HTTP requests to an external system to store the data
Some of these options will be more or less appropriate depending on your exact requirements, however, the general idea is that given a database API, you could implement the exact same method signatures with a completely different approach.
This is a question about using config files for my configuration or rather saving the configurations on my settings table on the database. The configurations change as they include usernames and passwords for APIs I am using. I have thought of saving sensitive information to config file and other settings to database. Is it really possible for me to create a config file in #app\config folder and declare global variable $cfg[] which I can call from all controllers and views? Another question withing this same question is, is it a security risk to use the database for configuration settings like API username and password?
If you are using advanced templates you can use param.php or local-param.phpcper management of global parameters that can be used any place you want. If these parameters are common to both the frontend backend it is appropriate indicate in the \ common.
For storing passwords in the database, or for their conservation in the configuration file param is purely a personal choice. I'm running through the files param very comfortable. The fact of creating a database table its model, controller, and CRUD is very easy with Yii2 especially using the automatic generator gii. Over the years I found the tables of database configurations rather awkward unless you use as structures and key value persistent and also why I found the facilities configuration Yii2 very practical
I'm currently developing a new project in Grails and right now all the information concerning datasources is within DataSource.groovy. I have also got some code in BootStrap.groovy in order to initialize the database in case of the first start in order to fill some tables with constant values.
Now I'm wondering how I could realize some kind of an "installer". I'm thinking of a customer who uses the .war of my software and needs to configure the database parameters (URL, user, password) before the first start.
I was thinking about setting up a dummy database and later let him change the URL, user and password via a webpage as part of my software. But what will then happen with my BootStrap-code in order to initialize the new database? Or is there a possibility of let the user set the necessary parameters before the BootStrap-code is executed and create the new database as well? Would that be possible to realize within grails or would I have to place some php-code up front?
I'm thinking of using grails, mysql in connection with database-migration plugin.
I would be grateful for any advice on this behalf. Thank you in advance!
If something is unclear, please tell me so.
I highly recommend you consider using an external configuration file that will allow your customers to not only configure the data source(s) but any other aspects of your application when they deploy it.
The Grails documentation has detailed information about how this is accomplished.
Some projects have properties have miscellaneous settings such as: "AllowPayments", "ShowSideBar", "SectionTitle". Really things that don't necessarily fit in to other objects.
How do you guys store these kinds of values? ApplicationSettings? Flat File? Database table?
How do you access them? Static object with properties? DB call?
Would either of these change if you were in a load balanced environment where you would have to synchronize the files across multiple servers?
Environment
ASP.NET 2.0
For me it depends on the context the setting is. If it relates to the data and the domain, i store in the database, if it relates the the application i store in the web.config.
App.Config, or a custom xml configuration file and config service. Key value pair mappings keeps things very simple.
Since you didn't tell which environment you use:
In .NET applications, I use the ApplicationSettings system from Visual Studio. This way you can configure the settings with default values in the designer, and a strongly-typed class to access the values is generated. I usually add a second ApplicationSettings element with the name Persistent in addition to the default Settings, with anything the user configures to go in the Settings object and anything I just save (i.e. window position) to the Persistent object.
This goes for desktop applications.