4 ms·

Full disclosure: I'm one of the rubber devs. But, did you look at any of the wiki pages? I think all of your questions are answered right there: https://gith

Full disclosure: I'm one of the rubber devs. But, did you look at any of the wiki pages? I think all of your questions are answered right there: https://github.com/wr0ngway/rubber/wiki https://github.com/wr0ngway/rubber/wiki I think you largely missed the point of rubber. Rubber could use something like fog (and indeed, we plan to), but it's not a fog competitor. It allows you to do role-based deployment with capistrano. At the core of it, you have a set of roles (e.g., app, db, redis, web, resque_worker) and a set of machines belonging to those roles. You have role-based config and you can interact with subsets of your cluster through those roles. heroku is good at what it does. But there is simply no way I could have built Mogotest on it. And most of the rubber projects I've come across would never work on heroku.

moe 16y ago
But, did you look at any of the wiki pages? Yes. I think all of your questions are answered No. I think you largely missed the point of rubber. Could be. My perception is that it wants to be a turnkey solution for people with little admin knowledge. But it is nowhere near that, in its current shape and form. At the core of it [...] Sure. It surely does some useful things. But none of that is nearly adequately documented. For example, what exactly does the command I cited do? I couldn't see it in the wiki. What if I want postgres instead of mysql? What about backups? How do I upgrade system packages later? Where is the /etc/hosts magic documented that the blog-post mentioned (which is a pretty bad idea btw)? What kind of network topology will my instances have, what are the security groups? How do I manage EBS volumes? What if I need a redis, memcached, or other components? What AMI will my instances be running? What about loadbalancing, failover? What about cronjobs, e-mail, all the systems stuff? ... I could go on for a while. Maybe I just didn't see the wiki-page where all this is explained. And I'm sure much of it can be "discovered" just by trying out and guessing. However, Heroku exists, is free, well tested and well documented. As such it's the better blackbox to choose for someone who doesn't yet know what he's doing. For people who know what they're doing there's fog, puppet and chef.
- nirvdrum 16y ago
  I have a feeling this discussion is going to go basically nowhere. But I'll bite. The command you cited is a generator. It generates a complete passenger and MySQL setup. It's a sensible default that handles a large set of use cases. If you want postgres instead, there's a complete_passenger_postgresql. The full list of modules can be seen at: https://github.com/wr0ngway/rubber/tree/master/lib/generators/vulcanize/templates https://github.com/wr0ngway/rubber/tree/master/lib/generator... Backups are set up automatically. There's a whole mess of capistrano tasks for this stuff. Run "cap -T" to see them. That's the standard way of documenting such. Actually, you have a load of questions there that are evident once you actually try rubber. That's not a great answer and I'm not saying the documentation is great. But, hey, the documentation for fog is virtually non-existent. But, no, rubber is absolutely not meant to be a turnkey solution. We grossly simplify a ton of tasks, but at the end of the day, you need to know what you want your topology to look like, what roles you want on which machines, how many of each, how many read slaves you want, etc. The templates we provide make setting up things like backup and slaves trivial, but we don't do it for you automatically.
  - moe 16y ago
    Well, I'm sorry for being entirely negative, but after looking over the templates... in my opinion you're doing it wrong. For example (at a glance) I don't see any mechanism to upgrade anything after the fact. Am I just missing that, or what's the approach there? Either way, it seems you're effectively reinventing a subset of puppet. Wouldn't it be more sensible to implement rubber in the form of puppet manifests (or chef recipes)?
    - nirvdrum 16y ago
      You're certainly entitled to your opinion. It's just a strong stance to take for something you surveyed for 15 min. and then proceeded to compare to a few things that don't make a ton of sense. But that may very well be due to holes in the docs (hopefully the article did give a motivating example though). I'd have to check the timeline again (I wasn't involved with rubber from the outset), but I think it predates both puppet & chef. Regardless, we've discussed adding a chef adapter. However, it's unlikely that would ever work with the chef configuration server since a large tenet of rubber is your entire deployment and provisioning configuration is wholly contained in your project. Re: upgrading. If you want to upgrade to the latest OS packages, you can "cap rubber:bootstrap" or use "cap invoke" to execute whatever command you want on the remote machines. If you're referring to the rubber modules, you just re-run the generator when we issue an update, much like with other generated source projects. Or modify any of the rubber-*.yml files to specify whatever version number you want, since it's in your version-controlled source tree. Don't get me wrong. I'm highly critical of the projects I'm involved in. It's the best motivator I can think of for improving things. I'm just trying to clear up any misunderstandings to elucidate real issues. I think the rubber mailing list might be a more appropriate venue for a technical deep dive, if you want. Or feel free to email me directly (nirvdrum@gmail). Or we could keep going back and forth here, but it doesn't feel very productive.

moe 16y ago

But, did you look at any of the wiki pages? Yes. I think all of your questions are answered No. I think you largely missed the point of rubber. Could be. My perception is that it wants to be a turnkey solution for people with little admin knowledge. But it is nowhere near that, in its current shape and form. At the core of it [...] Sure. It surely does some useful things. But none of that is nearly adequately documented. For example, what exactly does the command I cited do? I couldn't see it in the wiki. What if I want postgres instead of mysql? What about backups? How do I upgrade system packages later? Where is the /etc/hosts magic documented that the blog-post mentioned (which is a pretty bad idea btw)? What kind of network topology will my instances have, what are the security groups? How do I manage EBS volumes? What if I need a redis, memcached, or other components? What AMI will my instances be running? What about loadbalancing, failover? What about cronjobs, e-mail, all the systems stuff? ... I could go on for a while. Maybe I just didn't see the wiki-page where all this is explained. And I'm sure much of it can be "discovered" just by trying out and guessing. However, Heroku exists, is free, well tested and well documented. As such it's the better blackbox to choose for someone who doesn't yet know what he's doing. For people who know what they're doing there's fog, puppet and chef.

nirvdrum 16y ago
I have a feeling this discussion is going to go basically nowhere. But I'll bite. The command you cited is a generator. It generates a complete passenger and MySQL setup. It's a sensible default that handles a large set of use cases. If you want postgres instead, there's a complete_passenger_postgresql. The full list of modules can be seen at: https://github.com/wr0ngway/rubber/tree/master/lib/generators/vulcanize/templates https://github.com/wr0ngway/rubber/tree/master/lib/generator... Backups are set up automatically. There's a whole mess of capistrano tasks for this stuff. Run "cap -T" to see them. That's the standard way of documenting such. Actually, you have a load of questions there that are evident once you actually try rubber. That's not a great answer and I'm not saying the documentation is great. But, hey, the documentation for fog is virtually non-existent. But, no, rubber is absolutely not meant to be a turnkey solution. We grossly simplify a ton of tasks, but at the end of the day, you need to know what you want your topology to look like, what roles you want on which machines, how many of each, how many read slaves you want, etc. The templates we provide make setting up things like backup and slaves trivial, but we don't do it for you automatically.
- moe 16y ago
  Well, I'm sorry for being entirely negative, but after looking over the templates... in my opinion you're doing it wrong. For example (at a glance) I don't see any mechanism to upgrade anything after the fact. Am I just missing that, or what's the approach there? Either way, it seems you're effectively reinventing a subset of puppet. Wouldn't it be more sensible to implement rubber in the form of puppet manifests (or chef recipes)?
  - nirvdrum 16y ago
    You're certainly entitled to your opinion. It's just a strong stance to take for something you surveyed for 15 min. and then proceeded to compare to a few things that don't make a ton of sense. But that may very well be due to holes in the docs (hopefully the article did give a motivating example though). I'd have to check the timeline again (I wasn't involved with rubber from the outset), but I think it predates both puppet & chef. Regardless, we've discussed adding a chef adapter. However, it's unlikely that would ever work with the chef configuration server since a large tenet of rubber is your entire deployment and provisioning configuration is wholly contained in your project. Re: upgrading. If you want to upgrade to the latest OS packages, you can "cap rubber:bootstrap" or use "cap invoke" to execute whatever command you want on the remote machines. If you're referring to the rubber modules, you just re-run the generator when we issue an update, much like with other generated source projects. Or modify any of the rubber-*.yml files to specify whatever version number you want, since it's in your version-controlled source tree. Don't get me wrong. I'm highly critical of the projects I'm involved in. It's the best motivator I can think of for improving things. I'm just trying to clear up any misunderstandings to elucidate real issues. I think the rubber mailing list might be a more appropriate venue for a technical deep dive, if you want. Or feel free to email me directly (nirvdrum@gmail). Or we could keep going back and forth here, but it doesn't feel very productive.