I need to remove a few files when in development environment (for example when using Vagrant) but not in production. I want to disable firewalld when in development, but not in production. I would like to disable selinux whenon development, but not on production.
What is the best practice for doing these? I would like to use my puppet scripts both on development environments (with Vagrant) and on production.
It is not a good practice to have scripts specific to an environment. Instead you should have scripts which will behave differently based on environment. Let me show you how; there are two steps you will need to do for this to work:
Define environments
You will have to define environments - I would suggest directory based environments (Because config based environment support will be dropped eventually). How to setup environments is an intimate topic and I suggest you check out the documentation
Use environments in your code
Let's say you have defined environments such as dev, qa, uat, prod etc. You can get the name of current environment by using $environment variable. Your manifests should leverage the environment variable to decide weather a firewall should be enabled/disabled etc. For example:
(Modified based on Felix's comment, thanks #Felix)
include profile::webserver
if $environment != 'dev'
include profile::firewall
In above piece of code if the $environment does not match to "dev" only then the firewall role is applied!
Related
I have a general question about good practices and lets say way of work between docker and IDE.
Right now i am learning docker and docker compose, and i must admit that i like the idea of containers! Ive deployed my whole spring boot microservices architecture on containers, and everything is working really well!
The thing is, that in every place of properties when i am declaring localhost address, i was forced to change localhost to custom container names, for example localhost:8888 --> naming-server:8888. It is okay for running in containers, but obviously when i am trying to run this on IDE, it will fail. I like working/optimizing/debugging microservices in IDE, but i dont want rebuilding image and returning whole docker-compose every time i made a tiny small change.
What does it look like in real dev?
Regards!
In my day job there are at least four environments my code can run in: my desktop development environment, a developer-oriented container environment, and pre-production and production container environments. All four of these environments can have different values for things like host names. That means they must be configurable in some way.
If you've hard-coded localhost as a hostname in your application source code, it will not run in any environment other than your development system, and it needs to be changed to a configuration option.
From a pure-Docker point of view, making these configurable via environment variables is easiest (and Spring can set property values from environment variables). Spring also has the notion of a profile, which in principle matches the concept of having different settings for different environments, but injecting a whole profile configuration can be a little more complex at deployment time.
The other practice I've found helpful is to have the environment variable settings default to reasonable things for developers. The pre-production and production deployments are all heavily scripted and so there's a reasonably strong guarantee that they will have all of the correct environment variables set. If $PGHOST defaults to localhost that's right for a non-Docker developer, and all of the container-based setups can set an appropriate value for their environment at deploy time.
Even though our actual deployment system is based on containers (via Kubernetes) I do my day-to-day development in a mostly non-Docker environment. I can run an individual microservice by launching it from a shell prompt, possibly with setting some environment variables, and services have unit tests that can run just on the checked-out source tree, without needing any Docker at all. A second step is to build an image and deploy it into the development environment, and our CI system runs integration tests against the images it builds.
What's the best setup if you have multiple system like DEV, TEST, PROD with orchestrator?
Do you have one orchestrator for all and split robots with environment or do you have a separete orchestrator for each system.
I think it is more convinient to have all environments in one orchestrator but in this case you need to use a paid version
I was just checking on how pipelines work in Heroku. I want the staging and production apps to be the same except that they should access different API endpoints.
How could I achieve that?
Heroku encourages getting configuration from the environment:
A single app always runs in multiple environments, including at least on your development machine and in production on Heroku. An open-source app might be deployed to hundreds of different environments.
Although these environments might all run the same code, they usually have environment-specific configurations. For example, an app’s staging and production environments might use different Amazon S3 buckets, meaning they also need different credentials for those buckets.
An app’s environment-specific configuration should be stored in environment variables (not in the app’s source code). This lets you modify each environment’s configuration in isolation, and prevents secure credentials from being stored in version control. Learn more about storing config in the environment.
On a traditional host or when working locally, you often set environment variables in your .bashrc file. On Heroku, you use config vars.
In this instance you might use an environment variable called API_BASE that gets set to the base URL of your staging API on your staging instance and to the base URL of your production API in production.
Exactly how you read those values depends on the technology you're using, but if you look for "environment variables" in your language's documentation you should be able to get started.
I'm new to phoenix and elixier but the framework looks very interesting.
Currently i'm searching for an equivalent of Rails environment helpers.
Rails.env.production?
Rails.env.staging?
is there a similar implementation in phoenix ?
Best Regards
Eric
This function is not a part of the PhoenixFramework. Elixir's Mix supports three types of environment
Mix.env hold the current stage and give a result of :dev, :test, or :prod.
The develop option is used by default. On tests (mix test) the test environment will be automatically used.
This console call MIX_ENV=prod mix compile will compile the files in production environment.
See Introduction to mix for more information.
In addition to what Fabi755 said you may also interact with the different environments through the Application module. There are functions like Application.get_env/2 which can fetch the same configuration based on the environment you are currently in (like let's say have a config for sending SMS to false in dev, but you have it to true in prod).
Ultimately the environments are not from Phoenix but from Elixir and the Mix tool.
How do I best handle deployment of for example permissions that are different on different target environments? For example users, logins and permissions. I am now using manually created script files like this:
IF ##SERVERNAME='DEV'
-- dev environment code
IF ##SERVERNAME='PROD'
-- prod environment code
Is there a better way?
I ended up doing it through Publish profiles using different SSDT variables. That way if I have several different servers that could be "Production", I don't have a servername hard-coded in the project. I blogged about it here: http://schottsql.blogspot.com/2013/05/ssdt-setting-different-permissions-per.html
(Credit to Jamie Thomson for the original idea.)