Is there a tool similar to Ansible / Chef / Puppet to manage the configuration of a single instance / machine which keeps all setting in one place?
I'm thinking of some kind of text based configuration manager where you can put your settings into text files and apply all settings by issuing one command.
I really like the way Ansible works: Everything is nicely structured in yaml files and you can configure all sorts of dependencies / tasks / templates etc..
All of the above tools offer the possibility to run the client and server part on the same machine, but all were built to deploy settings on a large number or group of machines which seems to be overkill for this purpose. Or am I wrong?
You are wrong. Those tools are totally fine also for managing your workstation, all (Chef, Puppet, Ansible) also have a mode to work without any server/master - AFAIK Ansible even has no such thing at all.
Ansible works well for this task. A method that I have found works well is to setup a default inventory file and utilize the non-ssh connection type 'local' and it takes the command
ansible-playbook -i /path/to/inventory playbook.yml
down to
ansible-playbook playbook.yml
The Setup
Setting up the default inventory file
In /etc/ansible/hosts add an entry for localhost like so:
localhost ansible_connection=local
Related
I have a node.js application I have adopted from a more senior developer. I want to deploy it, and I know it will work because he already deployed it several times. I am reading these instructions:
https://galaxy-guide.meteor.com/deploy-quickstart.html
I use windows, as did he.
How does deployment work?
Take these instructions:
Windows If you are using Windows, the commands to deploy are slightly
different. You need to set the environment variable first, then run
the deployment command second (the syntax is the same as everything
you’d put for meteor deploy).
In the case of US East, the commands would be:
$ SET DEPLOY_HOSTNAME=galaxy.meteor.com
$ meteor deploy [hostname]
--settings path-to-settings.json
Am I just supposed to go to the source directory on my laptop and run these commands? What then happens? Is the source uploaded to their server from my laptop and then their magic takes care of the rest?
What about when I want to make a change to the code? Do I just do the same thing, poiting to an existing container and, again, they do the magic?
Am I just supposed to go to the source directory on my laptop and run these commands? What then happens? Is the source uploaded to their server from my laptop and then their magic takes care of the rest?
It is not magic. You basically go to your dev root and enter these commands. Under the hood it builds your app for production (including minification and prod flags for optimization) and once complete opens a connection to the aws infrastructure and pushes the build bundle.
See: https://github.com/meteor/meteor/blob/devel/tools/meteor-services/deploy.js
On the server there will be some install and post install scripts that set up all the environment for you and, if there are no errrors in the process, start your app.
These scripts have if course some automation, depending on your account settings and the commands you have entered.
What about when I want to make a change to the code? Do I just do the same thing, poiting to an existing container and, again, they do the magic?
You will have to rebuild (using the given deploy command) again but Galaxy will take care of the rest.
I am currently trying to automate the process of bamboo remote agent installation and uninstallation. I have run into a problem in regards to adding and removing capabilities.
What I am trying to automate:
(The following is what I do on the bamboo server via the GUI, I want to do this on the remote agent machine via bash script.)
I install the remote agent on a VM machine, then start it up. I go to the bamboo interface and click on the newly created agent's name.
I add a custom capability type, for the key I put 'buildserver' and for the value I put the name of the agent.
I add an 'Executable' capability of type 'Command' with Executable label 'cygwin' and path 'C:\cygwin64\bin\bash'
I navigate to the git executable, and remove it by clicking 'delete.' <--- (the problem step)
what I've done.
I have looked here and found a way to automate steps 1-3 using the following "bamboo-capabilities.properties" file:
buildserver="AGENTNAME"
system.builder.command.cygwin="C:\cygwin64\bin\bash"
However I am stuck on how I would remove the git capability (step 4.) I've tried something appending something like this to the file:
system.git.executable=""
but it does not seem to do anything. Does anyone know how I would do this? There seems to be very little documentation about this online.
Thanks very much.
I never found a way to get around this, but I found a workaround. I later learned the point of removing git in my situation was to allow a shared capability that was also called git to take precedence. My workaround was to set the non-shared capability to the value of the shared capability. I am not 100% sure that this does the same thing, and I am not in a position to test it yet, but as a capability seems to be only a key-value pair I don't see why it wouldn't.... will update if anything breaks.
I'm new to FreeBSD, coming from a Linux background. I want to install a port, changing one of the default configuration options, in a non-interactive way (so that I can script the installation for automated configuration of my FreeBSD servers).
As a specific example, the graphics/ImageMagick-nox11 port has a default configuration option of PERL=on. I want to change this. I realize that I can make config and then just use the generated entry in /var/db/ports/ to avoid any interaction in the future, but this still requires the initial interaction to set the options in the ncurses interface.
Ideally I want to be able to do something like the following, to build the package with perl support disabled but accepting all other defaults:
$ make PERL=off BATCH=yes install clean
What is the proper way to accomplish this? Can I somehow place port-specific configuration options like this in /etc/make.conf?
You can also unset OPTIONS via make.conf(5).
E.g.:
OPTIONS_UNSET=NLS
I am trying to set up a development environment with Vagrant. I am using centOS 6. From what I have read about Vagrant, I should set up provisioning scripts to install the packages I need when I run vagrant up. For me, this process takes quite a while. However, it seems like it would be more efficient to install everything one and create a new box. Is there some advantage to provisioning that I'm missing? What is it best for me to do in this case?
You can provision everything and when you want to run vagrant up for the nth time you can do so without provisioning:
vagrant up --no-provision
As to why provisioning? It's mostly so that you can easily take the base box and then change for example one or more items in the list to see the effect.
But it keeps the base clean and reusable.
I am currently trying to implement a one-click build solution (without having to start the monodevelop IDE) for my monotouch projects, where i could specify provisioning profiles and code signing certificates. I searched popular build tools like nant, ant and maven, but none seems to support monotouch. Has anyone tried something similar ?
I've gotten it work with Jenkins (aka Hudson).
You basically setup a Jenkins server, and setup your Mac as a "slave" build server. (I used a JNLP slave).
From there you can run any command line you want in the build, so you merely have to run mdtool with some arguments, like so:
/Applications/MonoDevelop.app/Contents/MacOS/mdtool -v build "--configuration:Release|iPhone" "Path/To/YourSolution.sln"
One thing to worry about is that to sign an iOS app, the slave process must run under your user. So you can't really create a Mac daemon for it, you'll have to run the slave process in startup for your user and minimize it, which is kind of annoying.
You tried teamcity? Might be worth you having a look at this thread Buildserver for MonoTouch upon OS X?
Thx for your answers. However i don't need to use such heavy artillery in this case. Since i'm developping a single and small app, I ended up by creating 3 different Build configurations in my solution, because i found out that it is possible to configure different codesign identities and provisioning profiles for each one (Development, Ad-Hoc, AppleStore), in the monodevelop project options menu.
Then in the AppleStore/Ad-Hoc configuration, i added post build commands, so i could create the .ipa file automatically (basically create a "Payload" folder and copy the .app file into it, and then zip it into a .ipa file, along with the icon and itunesartwork files).
Finally i created a bash script that invokes mdtool with any of the configurations, so i can build and generate .ipa executables by just executing the script.