How can meteor run on multiple ports.For example if the meteor run on 3000 i need another meteor app run on the same terminal.Please help me.
You can use the --port parameter:
`meteor run --port 3030`
To learn more about command line parameters, run meteor help <command>, e.g. meteor help run.
I see you've tagged your question meteor-up. If you're actually using mup, check out the env parameter in the config file.
I think the OP was referring to the exceptions caused because of locks on the mongo db. I am only on this platform for last week - and am learning as quick as I can. But when I tried running my application from the same project directory as two different users on two different ports - I got an exception about MongoDB :
Error: EBUSY, unlink 'D:\test\.meteor\local\db\mongod.lock'
The root of the issue isn't running on different ports - it is the shared files between the two instances - Specifically the database.
I don't think any of your answers actually helped him out. And .. neither can I yet.
I see two options -
First -
I am going to experiment with links to see if I can get the two users to use a different folder for the .meteor\local tree ... so both of us can work on the same code at the same time - but not impact each other when testing.
But I doubt if that is what the OP was referring to either (different users same app)...
Second - is trying to identify if I can inject into the run-mongo.js some concept of the URL / port number I am running on, so the mongodb.lock (and db of course) ... are named something like mongodb.lock-3000
I don't like the 2nd option because then I am on my own version of standard scripts.
B
No, it is mainly used the default port of 3000 or any state at the start, and the following (+1) to Mongo.
That is, the following application can be run through a 2-port, already in 3002, hence the previous 2-port as before - it is 2998.
Check can be very simple (Mac, Linux):
ps|grep meteor
Related
I've seen some post, including How to manage multiple backend stacks for development?, but nothing related to use lxc for a stable, safe and separate development environment, matching the production environment and regardless the desktop and/or linux distribution.
There was a feature previous to symfony cli release that allowed to specify a socket via ip:port, and this allowed to use different names in /etc/hosts using the 127.0.0.0/8 loopback network, so I could always use "bin/console server:start -p:myproject:8000", and I knew that using http://myproject:8000 (specified in /etc/hosts) I could access my project and keep the sessions, etc.
The symfony cli, as far as I've tried, doesn't allow this. Reading the docs, there's a built-in proxy in symfony cli, but though I've set a couple of projects to use this in the container, clicking on the list doesn't open the project (with .wip suffix), and issues an error about proxy redirections. If I browse to the port and ip of the container ip, it works perfectly, but the port is something that can change with every reboot of the container.
If there's nothing that can be set on the proxy side to solve this scenario, I'd ask to take back the socket feature that existed previously, so I can manage this situation as I used to do before, and solve this.
Thanks in advance.
I think I've finally found a good solution. I've created an issue to improve the situation that seemed not to work, so I'll try to explain for whoever might be interested.
I've setup the proxy server built-in with the symfony cli, but instead of allowing it to run with the defaults, I've had to specify --host=proxyhost (resolvable from the host) and setting proxy exceptions for .com, .org, .net, .tv, etc, together with setting a name to attach for every project (issuing symfony proxy:domain:attach myproject from inside the project dir), I can go to http://myproject.wip just like http://proxyhost:portX, no matter which port is portX.
I've recently started to play with DVC, and I was a bit surprised to see the getting started docs are suggesting to store .dvc/config in git.
This seemed like a fine idea at first, but then I noticed that my Azure Blob Storage account (i.e. my Azure username) is also stored in .dvc/config, which means it would end up in git. Making it not ideal for team collaboration scenarios.
What's even less ideal (read: really scary) is that connection strings entered using dvc remote modify blah connection_string ... also end up in .dvc/config, making them end up in git and, in the case of open source projects, making them end up in very interesting places.
Am I doing something obviously wrong? I wouldn't expect the getting started docs to go very deep into security issues, but I wouldn't expect them to store connection strings in source control either.
My base assumption is that I'm misunderstanding/misconfiguring something, I'd be curious to know what.
DVC has few "levels" of config, that can be controlled with proper flag:
--local - repository level, ignored by git by default - designated for project-scope, sensitive data
project - same as above, not ignored - designated to specify non-sensitive data (it is the default)
--global / --system - for common config for more repositories.
More information can be found in the docs.
Symfony introduced a new Dotenv component since Symfony 3 which allows us to handle environment variables as application parameters. This looks really nice and it's the best practice to follow according to 12factor app manifesto.
Now, regarding Symfony 4 they went further by pushing forward this practice and that's why I started using environment variables via the .env file.
And then I wanted to deploy and I realized that the .env file must not be persisted on the server as it would be the same as having a parameters.yml file.
So I've been digging into the documentation a bit and I found this article which explains that we can directly create environment variables via some webserver directives. That's great for code being executed via FPM but it does not tell us how to handle environment variables when running a command via the CLI for instance.
How can I achieve this ?
Should there be an equivalent of a .env file stored somewhere? But then parameters would be duplicated ?
I'm welcoming any help ;)
Finally had the time to check the link Neodan posted and everything is in there!
So for those of you wondering what to do, simply edit the /etc/environment file and add your variables. Then reboot your server and all your processes will have access to these variables.
I guess that's the simplest solution. The only drawback of this method is that these variables are available by any process / users but that's ok as far as I'm concerned.
If you want a more secure solution I suppose that you could, as I stated before, configure your webserver to add environment variables and export them via your .bash_profile or .bashrc file but be careful about how you start your shell (when deploying your application for instance). It's more complicated to maintain and prone to errors I'd say.
N.B.: You also might want to be careful about how you name your variables to prevent collisions.
This may not be possible at the moment but if anyone had the same problem, how did you handle it?
Is it possible to run the migrations on multiple servers at the same time without running the same scripts multiple times?
The problem I am having is that we are using multiple servers and they run the migrations every time we deploy a new version of our APP. This causes that the same migration scripts are being run several times (depending on how many servers are running it).
Is there a way to check whether the migration is in progress and if yes, skip it or this is something I would need to implement manually?
Many thanks.
This sounds like something you would need to implement manually.
I suggest having a script that executes once when you deploy your app that SSH into one of your servers and executes the migration.
I would recommend using Ansible to write a playbook to handle this, while calling all the relevant Hosts (inventories).
The end result would be something like (for example):
If you only wanted to run on a single (or subset list of..):
ansible-playbook --limit YOUR_INVENTORY_NAME run-migrations.yml
Or, for all of them as defined:
ansible-playbook run-migrations.yml
And your actual playbook within Ansible would look something like:
- name: Run Migrations
command: php bin/console doctrine:migrations:migrate
args:
chdir: /path/to/symfony
I am trying a test to move all my development to Nitrous.io IDE, but with limited space in my Nitrous box I want to permanently host my Mongo databases at MongoHQ.com. Currently each day I need to set my MONGO_URL by running:
export MONGO_URL='mongodb://<user>:<pass>#paulo.mongohq.com:12345/<db>'
If I fire up another console or logout of Nitrous my MONGO_URL needs to set again.
How can I set the development MONGO_URL for good per meteor app? I cannot find a config file anywhere.
Nitrous support helped me find a quick solution. Just wanted to answer it here for others with the same issue.
Open ~/.bash_profile and enter your DB information.
example:
export MONGO_URL='mongodb://jimmy:criket#paulo.mongohq.com:12345/mynitrobox'
Next in the console run source ~/.bash_profile to load the settings.
This sets the DB for your entire node.js box, not individual meteor apps, so you may want to structure your Mongo collections accordingly with subcollections.
you can do this in one line like so:
MONGO_URL='mongodb://<user>:<pass>#paulo.mongohq.com:12345/<db>' meteor
I don't know much about Nitrous.io but in AWS EC2 I have an upstart job that runs this for me when the server starts.
I gist'd my approach a while back, I've since changed it a bit but this still works:
https://gist.github.com/davidworkman9/6466734
I don't know that this will help you in Nitrous.io though, good luck!