That would almost certainly be a better idea, I'm not sure why we didn't think about that. It came at the end of a week-long push to get our project into production, I'm not sure our brains were fully functioning at that point...
On Monday, December 23, 2013 10:21:38 AM UTC-8, drewhk wrote: > > Hi Ryan, > > Is there any reason why you have not used the Amazon EC2 API? At one point > we used simply the Java API to discover nodes. > > -Endre > > > On Mon, Dec 23, 2013 at 1:49 AM, Ryan Tanner <[email protected]<javascript:> > > wrote: > >> We use Vagrant and Chef to deploy our Akka cluster on AWS. At the moment >> we're using a quite stupid method of service discovery: I wrote a bash >> script that uses "vagrant ssh" to get the IP of each EC2 instance after >> it's been created (curl'ing the AWS magic metadata IP) and then update the >> /etc/hosts on each box to provide it with the EC2 private IPs of the seed >> nodes. Any time a box is added or removed, this is re-run. You might be >> able to do something similar with docker. >> >> Really, we should use DNS (Route53 + API) or Zookeeper but for some >> reason this seemed reasonable at two o'clock in the morning. It's worked >> out well so far but we have less than ten nodes. >> >> >> On Sunday, December 22, 2013 7:33:00 AM UTC-8, ahjohannessen wrote: >>> >>> Roland, >>> >>> It would probably be a great help if there was some documentation about >>> service discovery and Akka. I often have wondered how people deal with >>> service discovery scenarios in the context of Akka applications. >>> >>> I am currently hacking up an akka-etcd client that I intend to use for a >>> similar scenario that Chris lines up. Reason being is that we intend to use >>> Linux containers (docker) and CoreOS as our baseline for all of our >>> services. >>> >>> >>> On Friday, December 13, 2013 12:32:46 PM UTC, Akka Team wrote: >>>> >>>> Hi Chris, >>>> >>>> >>>> On Fri, Dec 13, 2013 at 12:50 PM, oxbow_lakes <[email protected]>wrote: >>>> >>>>> For our applications which export remote APIs, we tend to follow this >>>>> mechanism: >>>>> >>>>> >>>>> - Server discovers free port on localhost >>>>> - Server binds address into a naming service (JNDI, Zookeeper etc) >>>>> - under a name - like "cool-thing/address/Live" >>>>> - Client uses name to lookup a service. Client can "listen" to >>>>> name to discover service changes (for example, migration to a new host) >>>>> >>>>> >>>>> The primary driver for this is that *no modification should be >>>>> required for me to migrate a service between hosts* >>>>> >>>> >>>> Sounds entirely reasonable. >>>> >>>> >>>>> >>>>> In Akka, there seem to be a few issues with this: >>>>> >>>>> 1. In my application.conf, I have to *explicitly* state what host my >>>>> server is running on >>>>> >>>>> netty.tcp { >>>>> hostname = "coolhost.intra.coolco.com" >>>>> } >>>>> >>>>> Why is this? >>>>> >>>> >>>> The actor system’s address must be clearly defined, without any magic >>>> in it (because that would make things difficult to understand). Therefore >>>> the hostname part must be chosen by the user. This does not mean in any >>>> way >>>> that you need to edit or even use a config file, you can as well set or >>>> override this property when creating the Config which you pass to the >>>> ActorSystem upon creation. We do that all the time in our tests: >>>> >>>> val config = ConfigFactory.parseString("akka.remote.netty.tcp { >>>> hostname=ZAPHOD\n port=42 }").withFallback(ConfigFactor.load()) >>>> val system = ActorSystem("Beeblebrox", config) >>>> >>>> How you obtain the right hostname string (which can either contain an >>>> IP or a resolvable name) depends on the environment you deploy into, >>>> therefore Akka cannot help you with that part. Whether a hostname is right >>>> is defined to answer the question of whether other hosts can connect to >>>> this actor system using that piece of information. >>>> >>>> >>>>> It means that, in order to move my server to startup on a new host I >>>>> need to either redeploy (because my application.conf is sitting in my >>>>> source dir) or at the very least edit a config file. I don't even >>>>> understand the requirement as being something typically required: when >>>>> I'm >>>>> running the system, it's implicit that the hostname is *this host*! Using >>>>> "localhost" doesn't work, however - and neither does ommitting hostname >>>>> entirely, where you get this error when a client tries to connect: >>>>> >>>>> [ERROR] [12/13/2013 11:23:17.927] >>>>> [gekkoRemoting-akka.actor.default-dispatcher-7] >>>>> [akka://gekkoRemoting/system/endpointManager/ >>>>> reliableEndpointWriter-akka.tcp%3A%2F%2Fpapagui%4010.210. >>>>> 51.121%3A52321-0/endpointWriter] dropping message [class >>>>> akka.actor.SelectChildName] for non-local recipient [Actor[akka.tcp:// >>>>> [email protected]:20000/]] arriving at >>>>> [akka.tcp://[email protected]:20000] >>>>> inbound addresses are [akka.tcp://[email protected]:20000] >>>>> >>>>> >>>>> >>>>> 2. If I let Akka discover a remoting port for me, I can't find out >>>>> what was chosen (or, if I can, I can't figure out how via the API). This >>>>> means I cannot bind my location into our naming system - so I have to >>>>> choose the port myself (not a disaster, of course, but unnecessary) >>>>> >>>> >>>> The default address is available on the ActorRefProvider interface, and >>>> extensions can access that on the ExtendedActorSystem. Direct drilling >>>> looks like >>>> >>>> val addr = system.asInstanceOf[ExtendedActorSystem].provider. >>>> getDefaultAddress >>>> >>>> >>>>> >>>>> I'm not necessarily talking about clusters here - but simple >>>>> client/server applications. Apologies if I'm complaining about things >>>>> which >>>>> are already possible! >>>>> >>>> >>>> Since you normally don’t need to know (and should not care) about >>>> transport details—assuming clustering ;-) —the docs contain more info >>>> under >>>> the topic “how to serialize an >>>> ActorRef<http://doc.akka.io/docs/akka/2.3-M1/scala/serialization.html#Serializing_ActorRefs> >>>> ”. >>>> >>>> >>>> Regards, >>>> >>>> Roland >>>> >>>> >>>>> >>>>> Chris >>>>> >>>>> -- >>>>> >>>>>>>>>> Read the docs: http://akka.io/docs/ >>>>> >>>>>>>>>> Check the FAQ: http://akka.io/faq/ >>>>> >>>>>>>>>> Search the archives: https://groups.google.com/ >>>>> group/akka-user >>>>> --- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "Akka User List" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to [email protected]. >>>>> To post to this group, send email to [email protected]. >>>>> Visit this group at http://groups.google.com/group/akka-user. >>>>> For more options, visit https://groups.google.com/groups/opt_out. >>>>> >>>> >>>> >>>> >>>> -- >>>> Akka Team >>>> Typesafe - The software stack for applications that scale >>>> Blog: letitcrash.com >>>> Twitter: @akkateam >>>> >>> -- >> >>>>>>>>>> Read the docs: http://akka.io/docs/ >> >>>>>>>>>> Check the FAQ: http://akka.io/faq/ >> >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user >> --- >> You received this message because you are subscribed to the Google Groups >> "Akka User List" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] <javascript:>. >> To post to this group, send email to [email protected]<javascript:> >> . >> Visit this group at http://groups.google.com/group/akka-user. >> For more options, visit https://groups.google.com/groups/opt_out. >> > > -- >>>>>>>>>> Read the docs: http://akka.io/docs/ >>>>>>>>>> Check the FAQ: http://akka.io/faq/ >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups "Akka User List" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/groups/opt_out.
