I am trying to deploy my own cluster using DC/OS CLI installation. Mesosphere has a huge support as there are many packages ready to install provided in Mesosphere Universe repo (https://github.com/mesosphere/universe).
However, I would like to make one step further. I am trying to install my own applications to my cluster using the DC/OS CLI installation process. To do this, as far as I understand, I need to either (i) make my application recognizable to the system repo (as the other repo packages that are provided in Universe) or (ii) make a new image that consists all my applications and modify the DC/OS script to make the installation possible.
Unfortunately, my modest knowledge is flawed and I could not find any where a clear answer to this.
Therefore, I would like to ask:
1) Is it possible to do what I am trying to do?
2) If the answer is YES, how exactly should I do? My goal is to install my awesome apps for my own purpose, not to publish them. But to add my apps as repo into Universe, it seems like I have to publish them.
It is possible! :)
Please follow these instructions
Related
I'm about to start a pretty huge project.
This project is a website.
The backend will be made with Node
The frontend will be made mostly with Angular
Backend is going to be an API (which is cool with Angular) but also (later) for an Android app.
Frontend is going to be a fork of this repo : https://github.com/maxime1992/webTemplate and I want to be able to pull from upstream to keep the fork up to date.
I am wondering. How should I manage it?
Should I create only one repo, containing back and frontend with Git submodule or subtree.
Should I create two separated repos, one for the frontend, one for the backend and then use symlink to have them together? But if someone wants to run it on Windows ... Too bad.
I want this project to be open source on GitHub so I would like to have something clear and easy for everyone :)
Tell me how you would do it, what's good, what's wrong ... I'm really curious!
As indicated in the comments, Git submodules (or Git subtrees) are not the right solution for this. Use a dependency management tool for this, which will work cross-platform (Linux, Mac, Windows), and is the standard way of doing this.
Separating your backend and frontend into separate projects is a good idea, as it will allow you to manage projects independently and add functionality or additional client applications later without bloating your application.
Since you're already using Angular for the frontend, I suggest you take a look at Bower, which is the de-facto standard dependency management tool for frontend projects. It allows you to define a bower.json file to define your dependencies, e.g. Angular and other frontend libraries, allowing you to assemble your frontend project without having to download and store libraries manually.
In your backend project, you would then also add a bower.json file which declares your frontend project as a dependency by pointing to its Git location and branch. Bower will then take care of downloading your frontend project and adding it into your backend project.
Check out some of the popular Bower tutorials for more info on this...
You can use bower link to automatically create symlinks between your projects - this will work across operating systems as well.
Some other tools that you might want to check out:
Yeoman for scaffolding a base project. There are some nice generators for scaffolding Angular projects, including things like LESS/SASS and Bootstrap (https://github.com/yeoman/generator-angular)
Wiredep for automatically wiring your Bower dependencies into your index.html file.
Getting your initial project setup right will be important. You can start small and grow things to a more advanced configuration later.
I was recently interviewed by a technical architect and he mentioned that his group has begun to consolidate all domain-based database calls into packages. He said this had significant advantages when sharing code and devising TDD (should.js). Is this a recommended practice? What are the advantages/disadvantages of using packages for encapsulating such resource IO? Please include links, if available. Thanks.
You can use npm packages to share code between projects since that's what packages do. Starting out with a package is probably a bad idea. You mostly start with a module and if needed extract out a package.
So I'm starting a web project from scratch on PHP/Zend Framework/SVN, and want to start it very structured. I know all about SVN branching, having a development branch, hot fix branch etc. (well at least I think I do).
My question is what's the best method to release new version of my software in the future, instead of just doing an svn update. For ex. deploy the new version to a test server for staging before releasing to production and such sort of things. Any thoughts?
As step 1, I wouldn't use a tool built to manage source code versioning for deployment, I'd recommend a tool that can manage/deploy releases for that purpose :)
I am a support analyst for BuildMaster, a tool which does exactly what you need (and it's free for you if you have a team of <= 5 people).
It really depends how your infrastructure looks like. If you are deploying to a lot of nodes I think using BitTorrent is a good choice
anyone has past experience with gradle? i'm thinking of using it for continuous deployment... i'm considering either using my own scripts (python) or gradle.
can anyone tell from experience which way he thinks recommanded to go? note i already use maven and i don't intend to move away for my dependency management and project management.
thanks
We have implemented Gradle-based deployment and environment management in a big governmental project (100+ servers). But we had to develop a custom set of plugins (which is actually rather straight forward process in Gradle) to handle tasks like remote SSH command execution through Groovy DSL, creation of application server domains/clusters (we are using WebLogic), application/configuration deployment.
We also are thinking of integrating Gradle with Puppet for easier Linux administration.
If you are coming from Java world, then using Gradle (which is Groovy-based) would be rather simple for you, because you can reuse your Java/Ant/Maven/Groovy knowledge to write scripts. Also an ability to create DSLs in Groovy may allow you to build interesting abstractions. Gradle also has very clean API which allows building nice dependencies between tasks. It also integrates very well with Maven infrastructure and you can reuse all Ant tasks.
Yes, Gradle-based deployment possible with gradle-ssh-plugin
Here is an article with good usage example.
Our team develops distributed winform apps. We use ClickOnce for deployment and are very pleased with it.
However, we've found the pain point with ClickOnce is in creating the deployments. We have the standard dev/test/production environments and need to be able to create deployments for each of these that install and update separate from one another. Also, we want control over what assemblies get deployed. Just because an assembly was compiled doesn't mean we want it deployed.
The obvious first choice for creating deployments is Visual Studio. However, VS really doesn't address the issues stated. The next in line is the SDK tool, Mage. Mage works OK but creating deployments is rather tedious and we don't want every developer having our code signing certificate and password.
What we ended up doing was rolling our own deployment app that uses the command line version of Mage to create the ClickOnce manifest files.
I'm satisfied with our current solution but is seems like there would be an industry-wide, accepted approach to this problem. Is there?
I would look at using msbuild. It has built in tasks for handling clickonce deployments. I included some references which will help you get started, if you want to go down this path. It is what I use and I have found it to fit my needs. With a good build process using msbuild, you should be able to accomplish squashing the pains you have felt.
Here is detailed post on how ClickOnce manifest generation works with MsBuild.
I've used nAnt to run the overall build strategy, but pass parameters into MSBuild to compile and create the deployment package.
Basically, nAnt calls into MSBuild for each environment you need to deploy to, and generates a separate deployment output for each. You end up with a folder and all ClickOnce files you need for every environment, which you can just copy out to the server.
This is how we handled multiple production environments as well -- we had separate instances of our application for the US, Canada, and Europe, so each build would end up creating nine deployments, three each for dev, qa, and prod.