Is there a way to run a command in puppet master that will bring changes to the hosts right away?
I have used different scripts using crontab to schedule my tasks and it changes whenever I have specified, but I am trying to learn if there is a way I can just hit the command in puppet master and boom! bring changes in the hosts(clients) immediately.
Let's say I want to change password in "cofig.properties" file in my 5 hosts. What would be the best way to do it from master without scheduling?
At work we
push git versioned control repos to a puppetmaster using a jenkins job,
then we use r10k to retrieve the control repo puppet module & hiera dependencies,
then we connect remotely using SSH to each node we want to update to run the relevant "puppet apply" command
It works smoothly.
I've solved that problem in my infrastructure by using Puppet for Configuration Management and SaltStack for orchestration.
I have the Puppet Agent apply a SaltStack module to automatically configure each node as a minion of my Salt Master (which is also my Puppet Master), then I just SSH into my master server and tell SaltStack to run the Puppet Agent on nodes that match my criteria.
There are several SaltStack modules on the Puppet Forge.
You could certainly use other tools, such as RunDeck, or even Puppet's own MCollective, but I personally found them to be more complicated to work with.
Related
I just installed bitnami/wordpress image using helm. Is it possible to sync it with git and when I will change some files in this git repository to update kubernetes pods?
I mean update Wordpress source code because Im modyficating plugins in wp-content/plugins dir.
You can use ArgoCD or Flux to automate this types of GitOps workflow. Check their documentation. They are pretty powerful and popular for GitOps in Kubernets.
A possible solution is to use git-sync in a sidecar container. It will periodically pull files down from a repository and copy them to a volume.
Here is a sample manifest which uses git-sync to update the content hosted on a simple nginx web server:
https://github.com/nigelpoulton/ps-vols-and-pods/blob/master/Multi-container-Pods/sidecar.yml
One way I managed it (although possibly a rookie way) was through github actions.
Here's an example of mine
And here's official docs from docker to configure with github actions
You basically want to tell github actions to recreate and push your image and then tell your cluster to refresh like so:
If you're using kubectl to manage your cluster check if your version supports kubectl rollout restart. You can use it to force any deployment to restart and smoothly recreate your pods (it also re-pulls the supporting image).
e.g.: kubectl rollout restart deployment/my_deployment
Is there a way to connect to cache instance (csession) remotely?
Let's say the intersystems is on a container, and I want to use csession on the remote server from my local machine, is there a way (without direct ssh) to run the cache instance?
I'm looking for an alternative way of these steps:
1- scp the cache script into the box
2- ssh into the box
3- run the csesion on the box
Any comments is really appreciated
You could use telnet (encrypted) But this wouldn't allow you to load scripts local to your machine.
One way would be to have your scripts in a git repository and add the loading of them into your instance as post-receive hook.
You might consider using https://intersystems-ru.github.io/webterminal/.
That is "web-based terminal for InterSystems Caché".
Standard procedure to start with
meteor app -p 3000&
This works, except when I close the ssh connection, application is no more running? I have no clue why this is happening.
Awakening Edit:
I use PM2 for traditional node apps, but if I have to setup process monitors, logs, database all by myself. I could just go back to reactjs and socketio and rock it with node.
Consider use mup package from Arunoda to easily deploy and run your app in production.
You could launch meteor with nohup (no hang-up) which serves this purpose.
nohup meteor --production &
But it's not a good idea to run a site in production with meteor anyway.
What should I do to run meteor forever ?
You can use forever, a Node.js tool designed to run node apps as services.
I also want to point that forever is getting old and I've heard of better recent alternatives but it seems to still be a pretty common tool. You could also use systemd which integrates better with the UNIX service ecosystem but that's anoter story.
But first, you'll have to "demeteorize" your meteor application like this :
cd my-project-meteor
meteor bundle --directory ../my-project-node
this is going to take some time
cd ../my-project-node/programs/server
npm install
this is going to take some time too
So now you have a plain node app, that you can run with node main.js
Let me mention that it might be a good idea to use the node version used by meteor which is 0.10.29 as of meteor 0.9.1 You can install it traditionally or you could use the node version that is shipped with the meteor tool.
sudo ln -s ~/.meteor/packages/meteor-tool/1.0.27/meteor-tool-os.linux.x86_64/dev_bundle/bin/node /usr/bin/node
sudo ln -s ~/.meteor/packages/meteor-tool/1.0.27/meteor-tool-os.linux.x86_64/dev_bundle/bin/npm /usr/bin/npm
Note that this way of "installing" node + npm on your system is problematic because :
it assumes you're doing only meteor related stuff.
it is dependant on the release process of the meteor tool (you'll need to rerun these commends if the meteor tool is updated).
You can install the forever tool using npm :
-g means globally : give access to forever to all users on the system
sudo npm install -g forever
To launch your node app as a service, you can use the following command, which sets correctly some environment variables and run the app using forever :
sudo export PORT=80 MONGO_URL=mongodb://localhost/my-project-mongodb ROOT_URL=http://localhost forever start my-project-node/main.js
You can monitor it using forever stop my-project-node/main.js
Also, what's the point of using 3rd party database service like https://mongolab.com/?
When using the meteor tool, it launches a mongod process automatically for you, and the underlying node process executed by meteor representing your app connects to this mongo instance.
When we want to launch our meteor app as a node app, we have to handle the mongo stuff ourself, which kinda answer the question : why not using another service to handle it for us, they know better, right ?
Doesn't it slow down the website, because now application has to connect to their database instead of local database ?
Of course, relying on a 3rd party database service has its inconvenients, and this is one of them. Network communications will always be slower than interprocess communications taking place on localhost (this is especially true on these SSD backed cheap VPS you can find nowadays).
And how exactly do I connect to mongolab for example ?
By setting an appropriate value to the environment variable MONGO_URL, the database service provider will give you an url that corresponds to your online mongodb, this is what you need to pass to the node process in command line if you want meteor to connect to your distant database and work as usual.
If you want to launch a dedicated local mongod instance to let your application connect to it, well this is another topic but you'll have to follow these steps :
first install mongodb correctly on your server, using the reference documentation for the OS version. By correctly I mean choose the same version as meteor is using currently (2.4.9) and let it run as a service so that it will actually restart when your server reboots.
test that mongod is running by launching a client with the mongo command.
pass the correct MONGO_URL when launching your app with forever (something like mongodb://localhost/my-project-mongodb)
Understand now why meteor deploy is amazing :D
Answer copy from here
In order to make a "one-click" start-up solution for Plone on a dedicated Mac web server, I would like to create an Automator application. The purpose of this would be so that it can be launched on login so that if the computer encountered a power outage or needed to restart for maintenance, Plone would automatically start once the machine was powered on again. That said, because the installation would be as root, the user and ".../zeocluster/bin/*" would need to be blessed in sudoers in order to run without needing a password to start plonectl.
Basic question: is it a huge security risk on a production server to add /bin/* to sudoers?
Zope will start as root, but will not run as root. After attaching to the port, it changes to the effective user specified in your buildout.
That said, unless you need to bind to a privileged port (like port 80 or 443), I would try to avoid starting Zope as root. It's just not necessary, and it increases the attack surface. For much the same reason, I'd avoid using automator for an app that starts as root.
Instead, take a look at the init_scripts directory in the Unified Installer. It has example startup scripts and packaging lists for OS X. These haven't been touched in a long time, so there's a good chance you'll need to edit to match the actual start commands. I'd also have it sudo to the effective user rather than start as root. So:
sudo -u plone_daemon /usr/local/Plone/zeocluster/bin/plonectl start
Adjusted to your install location.
Can you throw some points on how it is a best way, best practice
to install web application on Unixes?
Like:
where to place app and its bases and so for,
how to configure to be secure and easy to backup,
etc
For example I know such suggestion -- to set uniq user for each app.
App in question is Jira on FreeBSD, but more general suggestions are also welcomed.
Here's what I did for my JIRA install on Fedora Linux:
Create a separate user to run JIRA
Install JIRA under the JIRA user's home directory
Made a soft link "/home/jira/jira" pointing to the JIRA installation directory (the directory as installed contains the version number, something like /home/jira/atlassian-jira-enterprise-4.0-standalone)
Created an /etc/init.d script to run JIRA as a service, and added it to chkconfig so that it runs at system startup - see these instructions
Created a MySQL database for JIRA on a separate data volume
Set up scheduled XML backups via the JIRA admin interface
Set up a remote backup script to dump the MySQL database and copy the DB dump and XML backups to a separate backup server
In order to avoid having to open extra firewall ports, set up an Apache virtual host "jira.myhost.com" and used mod_proxy to forward requests to the JIRA URL.
I set everything up on a virtual machine (an Amazon EC2 instance in my case) and cloned the machine image so that I can easily restart a new instance if the current one goes down.