You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Jerry Malcolm <te...@malcolms.com> on 2019/07/19 17:38:37 UTC
OT: Tomcat on AWS for Dummies
I have had a dedicated hosted environment with WAMP and Tomcat for over
15 years. I'm very familiar with everything related to that
environment... apache http, mysql, dns server, the file system, JAMES,
and all of my management scripts that I've accumulated over the years.
Everything is in the same box and basically on the same desktop. But
now I have a client that has needs that are best met in an AWS
environment. I understand just enough AWS to be dangerous, which is not
much.... I do know that it's a bunch of different modules, and I
believe I lose the direct file system access. I've watched an AWS intro
video and a couple of youtube videos on setting up TC in AWS. But they
always starts with "now that you have your AWS environment set
up....". I am looking for something that explains the big picture of
migrating an existing WAMP+TC to AWS. I am not so naive to think that
there won't be significant rip-up to what I have now. But I don't want
to do unnecessary rip-up just because I don't understand where I'm
heading. Basically, I don't know enough to know what I don't know....
But I need to start planning ahead and learning soon if I'm going to
have any disasters in my code where I might have played it too loose
with accessing the file system directly in my dedicated environment.
Has anyone been down this path before and could point me to some
tutorials targeted to migrating WAMP+TC to AWS? Or possible hand-hold me
just a little...? I'm a pretty quick learner. I just don't know where
to start.
Thanks.
Jerry
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: OT: Tomcat on AWS for Dummies
Posted by Martynas Jusevičius <ma...@atomgraph.com>.
My advice when it comes to making your setup environment-agnostic:
Docker'ize it.
I haven't used Docker on AWS, but once you have an image running
locally you can be 98% sure it's gonna run on the server (e.g.
mounting files from host can cause some differences still, so best to
avoid that).
See if it makes sense: https://aws.amazon.com/docker/
On Fri, Jul 19, 2019 at 8:39 PM Jerry Malcolm <te...@malcolms.com> wrote:
>
> I have had a dedicated hosted environment with WAMP and Tomcat for over
> 15 years. I'm very familiar with everything related to that
> environment... apache http, mysql, dns server, the file system, JAMES,
> and all of my management scripts that I've accumulated over the years.
> Everything is in the same box and basically on the same desktop. But
> now I have a client that has needs that are best met in an AWS
> environment. I understand just enough AWS to be dangerous, which is not
> much.... I do know that it's a bunch of different modules, and I
> believe I lose the direct file system access. I've watched an AWS intro
> video and a couple of youtube videos on setting up TC in AWS. But they
> always starts with "now that you have your AWS environment set
> up....". I am looking for something that explains the big picture of
> migrating an existing WAMP+TC to AWS. I am not so naive to think that
> there won't be significant rip-up to what I have now. But I don't want
> to do unnecessary rip-up just because I don't understand where I'm
> heading. Basically, I don't know enough to know what I don't know....
> But I need to start planning ahead and learning soon if I'm going to
> have any disasters in my code where I might have played it too loose
> with accessing the file system directly in my dedicated environment.
>
> Has anyone been down this path before and could point me to some
> tutorials targeted to migrating WAMP+TC to AWS? Or possible hand-hold me
> just a little...? I'm a pretty quick learner. I just don't know where
> to start.
>
> Thanks.
>
> Jerry
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: OT: Tomcat on AWS for Dummies
Posted by Mark Eggers <it...@yahoo.com.INVALID>.
Chris,
> Jerry,
>
>> On 7/19/19 13:38, Jerry Malcolm wrote:
>>>>> I have had a dedicated hosted environment with WAMP and
>>>>> Tomcat for over 15 years. I'm very familiar with everything
>>>>> related to that environment... apache http, mysql, dns
>>>>> server, the file system, JAMES, and all of my management
>>>>> scripts that I've accumulated over the years. Everything is
>>>>> in the same box and basically on the same desktop. But now I
>>>>> have a client that has needs that are best met in an AWS
>>>>> environment.
>> Can you explain that in a little more depth? What is it about AWS
>> that meets their needs better?
>
>> I ask because you can provision a one-box wonder in AWS just like
>> you do on a physical space with a single server. You just have to
>> use remote-desktop to get into it, and then it's all the same.
>
>> But if they want to use RDS, auto-scaling, and other
>> Amazon-provided services then things can get confusing.
>>> Unfortunately, that is the precise reason we need to go AWS....
>>> Extremely high availability and scalability / load-balancing
>>> across multiple instances. There will need to at least one
>>> instance running at all times. Even when doing
>>> maintenance/upgrades on other instances.
>
> It's not "unfortunate" necessarily. At least it makes it clear why
> they want to migrate to AWS.
>
>> So the answer to your question really depends upon what the client
>> thinks they'll be getting by you taking your existing product "to
>> the cloud".
>
>>>>> I understand just enough AWS to be dangerous, which is not
>>>>> much.... I do know that it's a bunch of different modules,
>>>>> and I believe I lose the direct file system access.
>> That heavily depends upon how you do things. You can get yourself
>> a server with a disk and everything, just like you are used to
>> doing.
>>> Do you mean AWS offers a 'file server' module that I can
>>> basically access directly as a drive from TC? If so, that eases
>>> my mind a bunch. I manage and serve gigabytes of videos and
>>> photos. I don't really want a full CMS implementation. Just
>>> want a big hard drive I can get to.
>
> No, AWS doesn't really have a "file server" module that you can
> enable. Do you need a large disk for bulk storage? What are you
> storing? Perhaps switching over to a key-value store (which can act
> like a filesystem) or a document-store database (e.g. CouchDB) if you
> have fairly regular documents that you want to store. All of those
> technologies are quite cloud-friendly. You can even use them
> single-node if you want to make your application available to either
> AWS-based clients OR your more traditional one-box-wonder clients. Or,
> you can abstract your "write a file somewhere" process so that you can
> swap implementations at run-time: configuration says local-disk? Use
> FileWriter. Using CouchDB? Push the file to CouchDB through it's APIs.
>
What about using EFS (NFS store) in this environment? For Windows, an
NFS client would have to be installed, but that doesn't seem like much
of a barrier.
>
>>>>> I've watched an AWS intro video and a couple of youtube
>>>>> videos on setting up TC in AWS. But they always starts with
>>>>> "now that you have your AWS environment set up....". I am
>>>>> looking for something that explains the big picture of
>>>>> migrating an existing WAMP+TC to AWS. I am not so naive to
>>>>> think that there won't be significant rip-up to what I have
>>>>> now. But I don't want to do unnecessary rip-up just because I
>>>>> don't understand where I'm heading. Basically, I don't know
>>>>> enough to know what I don't know.... But I need to start
>>>>> planning ahead and learning soon if I'm going to have any
>>>>> disasters in my code where I might have played it too loose
>>>>> with accessing the file system directly in my dedicated
>>>>> environment.
>>>>>
>>>>> Has anyone been down this path before and could point me to
>>>>> some tutorials targeted to migrating WAMP+TC to AWS? Or
>>>>> possible hand-hold me just a little...? I'm a pretty quick
>>>>> learner. I just don't know where to start.
>> As usual, start with your requirements :)
>
>>> Requirements are what I have now in a single box, but with the
>>> addition of multiple instances of TC (and HTTPD and/or mySQL?)
>>> for HA and load balancing.
>
> One box with multi is ... not HA. Sorry. That allows you to do things
> like upgrade the application without taking it down completely. But it
> does not allow you to perform maintenance on the OS because everything
> has to come down.
>
>>> Day-1 launch won't be massive traffic and theoretically could be
>>> handled by my single dedicated server I have today. But if this
>>> takes off like the client predicts, I don't want to get caught
>>> flat-footed and have to throw together an emergency redesign to
>>> begin clustering TC to handle the traffic. Rather go live
>>> initially with single instance AWS, but with a thought-out (and
>>> tested/verified) plan to easily begin clustering when the need
>>> hits.
>
> One of the first things I'd take a look at is what it would take to
> switch from vanilla MySQL to one of the databases available through
> RDS. This sounds stupid: MySQL is available via RDS, so you're done,
> right? Well, it's not so simple. First of all, RDS is distributed by
> definition. So anything that affects e.g. MySQL when you go
> "distributed" means that your application has to handle it.
>
> For example -- and we're doing this right now with MariaDB -- when you
> program a simple JDBC transaction, you usually expect that an INSERT
> is going to fail if a record with the same PK already exists, and then
> you roll-back that transaction and you are done. The user has to try
> again maybe. You don't like that, so you do this:
>
> BEGIN
> SELECT id, foo, bar, baz FROM table WHERE id=? FOR UPDATE
>
> if(present)
> update row with new foo, bar, baz values
> update row
> else
> move to insert row
> update row with new foo, bar, baz values
> insert row
>
> COMMIT
>
> That's great, and it works perfectly on a single server. However, on
> multiple servers, you can get a failure on COMMIT because that's when
> the transaction is sent-around to the rest of the cluster.
>
> So if you want to have semantics like the above (create-or-update
> record), then you have to wrap pretty much every transaction in a "try
> it once; if you fail, rollback and try the exact same thing again".
> You need to do this because if you don't, you'll give your users way
> more unnecessary errors because simply re-trying the transaction will
> (likely) succeed because the contention has passed.
>
My understanding of multiple availability zone RDS is different. There's
a primary connection and endpoint, and then that endpoint is switched if
there's a failure. From the documentation that I've read, the actual
endpoint doesn't change, just where it actually points to.
Is this not your experience?
> I'm assuming that there isn't anything problematic about running
> multiple web application instances because you said you already run
> multi-instance. Don't run those on the same EC2 instance. Instead, run
> multiple EC2 instances.
>
> Load-balancing is easy, although I have to admit that I haven't
> figured out yet how to properly do "application load balancers" (I use
> old-school "Classic" ELB).
>
> Once you can (a) use ELB (b) have multiple EC2 instances for your
> applications and (c) use RDS, I think you'll be able to go into
> production like that and figure everything else out from there.
>
> I've really been hoping that someone can come to an ApacheCon and give
> a presentation about deploying Tomcat-based web applications to AWS.
> Especially talking about auto-scaling and stuff like that.
>
> Jean-Frederic has been showing his "to the cloud" presentation but
> it's not nearly to the level of detail that I'd like to see. Yes, I
> can see that he has been able to do it, but I have no idea HOW it has
> been done. What is the role of e.g. Kubernetes? How does one provision
> those services to get started? What do you need to start with one
> node? How do you move to 2 nodes? What about arbitrary auto-scaling
> with AWS? These are the kinds of things I want to see.
>
> -chris
I'm slowly working through all of those issues. I hope to have something
documented by the end of this year.
I'm trying to do this without Docker, without Netflix's Spinnaker, etc.
However, a suitably configured Docker image (application, Tomcat, Redis
client) works really well locally. I can spin up lots of containers and
it all just works (as long as the application is well-behaved). I'm just
using swarms right now. I'll try it with Kubernetes soon.
I've tried Elastic Beanstalk, but I was not impressed with deployment
speed. I also make use of versioned deployments in a more traditional
environment, and I find that to be useful.
What I'm looking at now is Elastic Groups and deployment with a CI/CD
platform such as Jenkins. How do you tell how many EC2 instances do you
have in your group and target them? One possible solution would be to
deploy to an S3 bucket, trigger an event to send information into a
message queue, and then have each EC2 instance poll the queue to do the
actual deployment.
That sounds like a LOT of plumbing, and sort of counter to the
philosophy of AWS. I'm still thinking about it.
Hacking around with application load balancers and multiple Elastic
Beanstalk groups might be another solution, but you have to play some
undocumented games with AWS. That always raises alarm bells.
I move at my client's pace, but hopefully this will happen sooner than
later.
. . . just my two cents
/mde/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
Re: OT: Tomcat on AWS for Dummies
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Jerry,
> On 7/19/19 13:38, Jerry Malcolm wrote:
>>>> I have had a dedicated hosted environment with WAMP and
>>>> Tomcat for over 15 years. I'm very familiar with everything
>>>> related to that environment... apache http, mysql, dns
>>>> server, the file system, JAMES, and all of my management
>>>> scripts that I've accumulated over the years. Everything is
>>>> in the same box and basically on the same desktop. But now I
>>>> have a client that has needs that are best met in an AWS
>>>> environment.
> Can you explain that in a little more depth? What is it about AWS
> that meets their needs better?
>
> I ask because you can provision a one-box wonder in AWS just like
> you do on a physical space with a single server. You just have to
> use remote-desktop to get into it, and then it's all the same.
>
> But if they want to use RDS, auto-scaling, and other
> Amazon-provided services then things can get confusing.
>> Unfortunately, that is the precise reason we need to go AWS....
>> Extremely high availability and scalability / load-balancing
>> across multiple instances. There will need to at least one
>> instance running at all times. Even when doing
>> maintenance/upgrades on other instances.
It's not "unfortunate" necessarily. At least it makes it clear why
they want to migrate to AWS.
> So the answer to your question really depends upon what the client
> thinks they'll be getting by you taking your existing product "to
> the cloud".
>
>>>> I understand just enough AWS to be dangerous, which is not
>>>> much.... I do know that it's a bunch of different modules,
>>>> and I believe I lose the direct file system access.
> That heavily depends upon how you do things. You can get yourself
> a server with a disk and everything, just like you are used to
> doing.
>> Do you mean AWS offers a 'file server' module that I can
>> basically access directly as a drive from TC? If so, that eases
>> my mind a bunch. I manage and serve gigabytes of videos and
>> photos. I don't really want a full CMS implementation. Just
>> want a big hard drive I can get to.
No, AWS doesn't really have a "file server" module that you can
enable. Do you need a large disk for bulk storage? What are you
storing? Perhaps switching over to a key-value store (which can act
like a filesystem) or a document-store database (e.g. CouchDB) if you
have fairly regular documents that you want to store. All of those
technologies are quite cloud-friendly. You can even use them
single-node if you want to make your application available to either
AWS-based clients OR your more traditional one-box-wonder clients. Or,
you can abstract your "write a file somewhere" process so that you can
swap implementations at run-time: configuration says local-disk? Use
FileWriter. Using CouchDB? Push the file to CouchDB through it's APIs.
>>>> I've watched an AWS intro video and a couple of youtube
>>>> videos on setting up TC in AWS. But they always starts with
>>>> "now that you have your AWS environment set up....". I am
>>>> looking for something that explains the big picture of
>>>> migrating an existing WAMP+TC to AWS. I am not so naive to
>>>> think that there won't be significant rip-up to what I have
>>>> now. But I don't want to do unnecessary rip-up just because I
>>>> don't understand where I'm heading. Basically, I don't know
>>>> enough to know what I don't know.... But I need to start
>>>> planning ahead and learning soon if I'm going to have any
>>>> disasters in my code where I might have played it too loose
>>>> with accessing the file system directly in my dedicated
>>>> environment.
>>>>
>>>> Has anyone been down this path before and could point me to
>>>> some tutorials targeted to migrating WAMP+TC to AWS? Or
>>>> possible hand-hold me just a little...? I'm a pretty quick
>>>> learner. I just don't know where to start.
> As usual, start with your requirements :)
>
>> Requirements are what I have now in a single box, but with the
>> addition of multiple instances of TC (and HTTPD and/or mySQL?)
>> for HA and load balancing.
One box with multi is ... not HA. Sorry. That allows you to do things
like upgrade the application without taking it down completely. But it
does not allow you to perform maintenance on the OS because everything
has to come down.
>> Day-1 launch won't be massive traffic and theoretically could be
>> handled by my single dedicated server I have today. But if this
>> takes off like the client predicts, I don't want to get caught
>> flat-footed and have to throw together an emergency redesign to
>> begin clustering TC to handle the traffic. Rather go live
>> initially with single instance AWS, but with a thought-out (and
>> tested/verified) plan to easily begin clustering when the need
>> hits.
One of the first things I'd take a look at is what it would take to
switch from vanilla MySQL to one of the databases available through
RDS. This sounds stupid: MySQL is available via RDS, so you're done,
right? Well, it's not so simple. First of all, RDS is distributed by
definition. So anything that affects e.g. MySQL when you go
"distributed" means that your application has to handle it.
For example -- and we're doing this right now with MariaDB -- when you
program a simple JDBC transaction, you usually expect that an INSERT
is going to fail if a record with the same PK already exists, and then
you roll-back that transaction and you are done. The user has to try
again maybe. You don't like that, so you do this:
BEGIN
SELECT id, foo, bar, baz FROM table WHERE id=? FOR UPDATE
if(present)
update row with new foo, bar, baz values
update row
else
move to insert row
update row with new foo, bar, baz values
insert row
COMMIT
That's great, and it works perfectly on a single server. However, on
multiple servers, you can get a failure on COMMIT because that's when
the transaction is sent-around to the rest of the cluster.
So if you want to have semantics like the above (create-or-update
record), then you have to wrap pretty much every transaction in a "try
it once; if you fail, rollback and try the exact same thing again".
You need to do this because if you don't, you'll give your users way
more unnecessary errors because simply re-trying the transaction will
(likely) succeed because the contention has passed.
I'm assuming that there isn't anything problematic about running
multiple web application instances because you said you already run
multi-instance. Don't run those on the same EC2 instance. Instead, run
multiple EC2 instances.
Load-balancing is easy, although I have to admit that I haven't
figured out yet how to properly do "application load balancers" (I use
old-school "Classic" ELB).
Once you can (a) use ELB (b) have multiple EC2 instances for your
applications and (c) use RDS, I think you'll be able to go into
production like that and figure everything else out from there.
I've really been hoping that someone can come to an ApacheCon and give
a presentation about deploying Tomcat-based web applications to AWS.
Especially talking about auto-scaling and stuff like that.
Jean-Frederic has been showing his "to the cloud" presentation but
it's not nearly to the level of detail that I'd like to see. Yes, I
can see that he has been able to do it, but I have no idea HOW it has
been done. What is the role of e.g. Kubernetes? How does one provision
those services to get started? What do you need to start with one
node? How do you move to 2 nodes? What about arbitrary auto-scaling
with AWS? These are the kinds of things I want to see.
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl0zFNAACgkQHPApP6U8
pFi6aBAAjaa3dxJqf05te+3FU8m96nVoy1uNwmRo9bho3/I9mnqgSfnhaVRK/hoj
iDY5liszC41nT30r+1cJLl3W59PECGS0oPWU3f8G7nI3F9gg7g3NcE1GvawiIzsx
Y4iklZ7Cz3w54v3oqq3JcWKDoPL94BFl513+7HwIIKv6qVARrzQI+6YONG6pw1Or
kgi1j9CrS8sZKL1MLCDPcGkCID+nw/WdlNtVsYRwJsgLELH9YwL2HKBqZ+nQDWhW
4jwzNogzzWbKYFSVbbDRYiW7f5os/YrDs8QXFGBM8fYyNJIC7R5v/tf0qiojxm6t
smWfiY6W4VM14cCCaM1kcRw5YUpO9E3o5ZXrSlNtCbG9qdi+wCMmYdbdVyBpPc2d
m1wN/BI9QEWNNPaUlVO8Fr6zw+pyrt1AW6HUYs/k7juhy6PjucGD7+iDAI1Xgzkc
XTrIz0aCvnGIkfrbDi4ERz3l41xZq1sOMd0yAQJf/S/RpQphGGNxZFItxs7aj6PN
g+u8nsMnK///Z2ky6qAV2sHBKeQ9PxYqr1fuwQgisUxuFXDO/Alfg7TNc04/iuGq
JwGloJ81wtngpM8e3hpWqOQH51j79Fk/Gb0Sql5SVxZvwxec5Gm8LZe0f86ONpLI
3yAgFiq2uaOuteHxptZtJcFdgMrqMQ0iOvRstXg0w60uqgNfRA0=
=SorY
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: OT: Tomcat on AWS for Dummies
Posted by Mark Eggers <it...@yahoo.com.INVALID>.
> Jerry,
>
> On 7/19/19 13:38, Jerry Malcolm wrote:
>>>> I have had a dedicated hosted environment with WAMP and Tomcat for
>>>> over 15 years. I'm very familiar with everything related to that
>>>> environment... apache http, mysql, dns server, the file system,
>>>> JAMES, and all of my management scripts that I've accumulated over
>>>> the years. Everything is in the same box and basically on the same
>>>> desktop. But now I have a client that has needs that are best met
>>>> in an AWS environment.
> Can you explain that in a little more depth? What is it about AWS that
> meets their needs better?
>
> I ask because you can provision a one-box wonder in AWS just like you
> do on a physical space with a single server. You just have to use
> remote-desktop to get into it, and then it's all the same.
>
> But if they want to use RDS, auto-scaling, and other Amazon-provided
> services then things can get confusing.
>> Unfortunately, that is the precise reason we need to go AWS....
>> Extremely high availability and scalability / load-balancing across
>> multiple instances. There will need to at least one instance running at
>> all times. Even when doing maintenance/upgrades on other instances.
>
> So the answer to your question really depends upon what the client
> thinks they'll be getting by you taking your existing product "to the
> cloud".
>
>>>> I understand just enough AWS to be dangerous, which is not
>>>> much.... I do know that it's a bunch of different modules, and I
>>>> believe I lose the direct file system access.
> That heavily depends upon how you do things. You can get yourself a
> server with a disk and everything, just like you are used to doing.
>> Do you mean AWS offers a 'file server' module that I can basically
>> access directly as a drive from TC? If so, that eases my mind a bunch.
>> I manage and serve gigabytes of videos and photos. I don't really want
>> a full CMS implementation. Just want a big hard drive I can get to.
>
>>>> I've watched an AWS intro video and a couple of youtube videos on
>>>> setting up TC in AWS. But they always starts with "now that you
>>>> have your AWS environment set up....". I am looking for something
>>>> that explains the big picture of migrating an existing WAMP+TC to
>>>> AWS. I am not so naive to think that there won't be significant
>>>> rip-up to what I have now. But I don't want to do unnecessary
>>>> rip-up just because I don't understand where I'm heading.
>>>> Basically, I don't know enough to know what I don't know.... But I
>>>> need to start planning ahead and learning soon if I'm going to have
>>>> any disasters in my code where I might have played it too loose
>>>> with accessing the file system directly in my dedicated
>>>> environment.
>>>>
>>>> Has anyone been down this path before and could point me to some
>>>> tutorials targeted to migrating WAMP+TC to AWS? Or possible
>>>> hand-hold me just a little...? I'm a pretty quick learner. I just
>>>> don't know where to start.
> As usual, start with your requirements :)
>
>> Requirements are what I have now in a single box, but with the addition
>> of multiple instances of TC (and HTTPD and/or mySQL?) for HA and load
>> balancing. Day-1 launch won't be massive traffic and theoretically
>> could be handled by my single dedicated server I have today. But if
>> this takes off like the client predicts, I don't want to get caught
>> flat-footed and have to throw together an emergency redesign to begin
>> clustering TC to handle the traffic. Rather go live initially with
>> single instance AWS, but with a thought-out (and tested/verified) plan
>> to easily begin clustering when the need hits.
>
>> Thanks again for the info.
>
>
> -chris
There are a lot of ways to approach this. I'm not sure how much is
viable under Windows, since I've only done Linux EC2 instances.
Load balancing:
You can't do multicasting (last I checked) in a cloud environment.
You'll need to use something like redis or memcache if you need to
support sessions / load balancing without sticky sessions. I recommend
steering away from sticky sessions because that complicates outages /
maintenance.
Database:
I'd look at RDS and multiple instances across availability zones. There
are some issues with fail-over and the time it takes. Look at recent AWS
forums for work-arounds.
Disks:
I think that one good design (if you can't do Docker or Elastic
Beanstalk) is to place all of your tools on an EBS volume. You can mount
this on Windows (I think - works with Linux), and access all of your
services from there.
There are several advantages to this. Backups are done by doing
snapshots of unmounted disks. You basically do the following:
1. Disconnect an instance from a load balancer
2. Unmount the driver from the instance
3. Perform the snapshot command
4. Once the snapshot command returns, remount the drive
5. Add the instance back to the load balancer
Server instances:
In a cloud environment, server instances are ephemeral. Be prepared to
lose a server at any time (I have). It's best to do load balancing, and
then place all of your "stuff" on EBS - mounted disks. It's
operationally niceer to do Docker or Elastic Beanstalk with
microservices, but I don't know if your software is designed that way.
Another way to handle monolithic services is to place the generic
services on the disk, and use something like Jenkins (or another CI/CD
tool) to deploy your applications to the services. Finally, keep the
versioned applications on an S3 instance, and use the CI/CD tool to
deploy from there. Then there's less need to do traditional backups.
If you keep your platforms generic and deploy to those platforms, you
can make your servers part of an elastic group. Then they can be built
properly when you need them. You may need to do some CloudFormation
magic to get everything put back together properly.
The tough concept to wrap your head around when you're coming from a
traditional environment is that your infrastructure is ephemeral and
code-based. Store components in S3. Store configurations in
CloudFormation. Spread out your database in a multi-zone RDS. Do
distributed session management with redis or memcache.
Reading and piecing together AWS documentation is challenging. The
documentation is pretty good on the tool set, but pretty awful when
trying to build an entire environment. It usually takes several
iterations to get things right.
I've not even discussed remote access, two factor authentication, and
public versus private networks.
This is way off topic from the Tomcat mailing list, but I hope that it
gets you started.
. . . just my two cents
/mde/
Re: OT: Tomcat on AWS for Dummies
Posted by Jerry Malcolm <te...@malcolms.com>.
Christopher,
On 7/19/2019 1:40 PM, Christopher Schultz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Jerry,
>
> On 7/19/19 13:38, Jerry Malcolm wrote:
>> I have had a dedicated hosted environment with WAMP and Tomcat for
>> over 15 years. I'm very familiar with everything related to that
>> environment... apache http, mysql, dns server, the file system,
>> JAMES, and all of my management scripts that I've accumulated over
>> the years. Everything is in the same box and basically on the same
>> desktop. But now I have a client that has needs that are best met
>> in an AWS environment.
> Can you explain that in a little more depth? What is it about AWS that
> meets their needs better?
>
> I ask because you can provision a one-box wonder in AWS just like you
> do on a physical space with a single server. You just have to use
> remote-desktop to get into it, and then it's all the same.
>
> But if they want to use RDS, auto-scaling, and other Amazon-provided
> services then things can get confusing.
Unfortunately, that is the precise reason we need to go AWS....
Extremely high availability and scalability / load-balancing across
multiple instances. There will need to at least one instance running at
all times. Even when doing maintenance/upgrades on other instances.
>
> So the answer to your question really depends upon what the client
> thinks they'll be getting by you taking your existing product "to the
> cloud".
>
>> I understand just enough AWS to be dangerous, which is not
>> much.... I do know that it's a bunch of different modules, and I
>> believe I lose the direct file system access.
> That heavily depends upon how you do things. You can get yourself a
> server with a disk and everything, just like you are used to doing.
Do you mean AWS offers a 'file server' module that I can basically
access directly as a drive from TC? If so, that eases my mind a bunch.
I manage and serve gigabytes of videos and photos. I don't really want
a full CMS implementation. Just want a big hard drive I can get to.
>
>> I've watched an AWS intro video and a couple of youtube videos on
>> setting up TC in AWS. But they always starts with "now that you
>> have your AWS environment set up....". I am looking for something
>> that explains the big picture of migrating an existing WAMP+TC to
>> AWS. I am not so naive to think that there won't be significant
>> rip-up to what I have now. But I don't want to do unnecessary
>> rip-up just because I don't understand where I'm heading.
>> Basically, I don't know enough to know what I don't know.... But I
>> need to start planning ahead and learning soon if I'm going to have
>> any disasters in my code where I might have played it too loose
>> with accessing the file system directly in my dedicated
>> environment.
>>
>> Has anyone been down this path before and could point me to some
>> tutorials targeted to migrating WAMP+TC to AWS? Or possible
>> hand-hold me just a little...? I'm a pretty quick learner. I just
>> don't know where to start.
> As usual, start with your requirements :)
Requirements are what I have now in a single box, but with the addition
of multiple instances of TC (and HTTPD and/or mySQL?) for HA and load
balancing. Day-1 launch won't be massive traffic and theoretically
could be handled by my single dedicated server I have today. But if
this takes off like the client predicts, I don't want to get caught
flat-footed and have to throw together an emergency redesign to begin
clustering TC to handle the traffic. Rather go live initially with
single instance AWS, but with a thought-out (and tested/verified) plan
to easily begin clustering when the need hits.
Thanks again for the info.
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl0yDpIACgkQHPApP6U8
> pFj5GA/+Pr+CXtOGTYsZqCWVT7KYqvAulyyyZsHOvS2oaiapjrsWORYA5rzS478y
> TE+rMAUc7ep0RToW1ZCAhtyKi+M1vfIwGu6qkFA6NCBWKL92I8jaFw+j/pDJ0mSJ
> sfv0OGu8hAmQwy2FCpscgFR9PBKNzJN3o5OhR0cp1g0i6/J5Ci9xkn92KVAv1ZIU
> WjY+WrE9tcqtASHjO/wS53YreHlXoPLSzhpbjwje/HzKkBYXRV9dRIpHLnOSNc6t
> +5LhnLghVR27J3n/w1xFeO8kM3SBySuCHhUGTNCKdxMlrprxCIwZjvgLwHBxwv17
> tK6NOxmuk4xsi7vrKGhR/PWYHuTMNrYkWwD3Hv2vskwqo4RioIOaseoXBGHYy/WN
> iDwN6viSzSCqivP+MLBGi00Xo3LFdJZu+DMufX05SYJvRxxO6yaNMxING7zr9ubJ
> ossrDNIkHSDs4J0SAvzYidfPCOUbRWvHI6dYLkqsieRk7pWp2JPSWBWKuisllBnP
> VOv4IaVfZNHGE5TmkWElKE8Cbyj8xxSerFN15RjoawmwnnP9c1L8LirTi/l7GEQN
> HlQfNFP+evIbGpPOrcUpZJa5sjfePeUl+jJj08DPw0djyG3K3tAcBQTO4LjqsKTC
> g1phEO502BxE8v1UPTpEYXGfxhvMSirvjC37lXbTabNo3R4Tbt4=
> =SUFA
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: OT: Tomcat on AWS for Dummies
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Jerry,
On 7/19/19 13:38, Jerry Malcolm wrote:
> I have had a dedicated hosted environment with WAMP and Tomcat for
> over 15 years. I'm very familiar with everything related to that
> environment... apache http, mysql, dns server, the file system,
> JAMES, and all of my management scripts that I've accumulated over
> the years. Everything is in the same box and basically on the same
> desktop. But now I have a client that has needs that are best met
> in an AWS environment.
Can you explain that in a little more depth? What is it about AWS that
meets their needs better?
I ask because you can provision a one-box wonder in AWS just like you
do on a physical space with a single server. You just have to use
remote-desktop to get into it, and then it's all the same.
But if they want to use RDS, auto-scaling, and other Amazon-provided
services then things can get confusing.
So the answer to your question really depends upon what the client
thinks they'll be getting by you taking your existing product "to the
cloud".
> I understand just enough AWS to be dangerous, which is not
> much.... I do know that it's a bunch of different modules, and I
> believe I lose the direct file system access.
That heavily depends upon how you do things. You can get yourself a
server with a disk and everything, just like you are used to doing.
> I've watched an AWS intro video and a couple of youtube videos on
> setting up TC in AWS. But they always starts with "now that you
> have your AWS environment set up....". I am looking for something
> that explains the big picture of migrating an existing WAMP+TC to
> AWS. I am not so naive to think that there won't be significant
> rip-up to what I have now. But I don't want to do unnecessary
> rip-up just because I don't understand where I'm heading.
> Basically, I don't know enough to know what I don't know.... But I
> need to start planning ahead and learning soon if I'm going to have
> any disasters in my code where I might have played it too loose
> with accessing the file system directly in my dedicated
> environment.
>
> Has anyone been down this path before and could point me to some
> tutorials targeted to migrating WAMP+TC to AWS? Or possible
> hand-hold me just a little...? I'm a pretty quick learner. I just
> don't know where to start.
As usual, start with your requirements :)
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl0yDpIACgkQHPApP6U8
pFj5GA/+Pr+CXtOGTYsZqCWVT7KYqvAulyyyZsHOvS2oaiapjrsWORYA5rzS478y
TE+rMAUc7ep0RToW1ZCAhtyKi+M1vfIwGu6qkFA6NCBWKL92I8jaFw+j/pDJ0mSJ
sfv0OGu8hAmQwy2FCpscgFR9PBKNzJN3o5OhR0cp1g0i6/J5Ci9xkn92KVAv1ZIU
WjY+WrE9tcqtASHjO/wS53YreHlXoPLSzhpbjwje/HzKkBYXRV9dRIpHLnOSNc6t
+5LhnLghVR27J3n/w1xFeO8kM3SBySuCHhUGTNCKdxMlrprxCIwZjvgLwHBxwv17
tK6NOxmuk4xsi7vrKGhR/PWYHuTMNrYkWwD3Hv2vskwqo4RioIOaseoXBGHYy/WN
iDwN6viSzSCqivP+MLBGi00Xo3LFdJZu+DMufX05SYJvRxxO6yaNMxING7zr9ubJ
ossrDNIkHSDs4J0SAvzYidfPCOUbRWvHI6dYLkqsieRk7pWp2JPSWBWKuisllBnP
VOv4IaVfZNHGE5TmkWElKE8Cbyj8xxSerFN15RjoawmwnnP9c1L8LirTi/l7GEQN
HlQfNFP+evIbGpPOrcUpZJa5sjfePeUl+jJj08DPw0djyG3K3tAcBQTO4LjqsKTC
g1phEO502BxE8v1UPTpEYXGfxhvMSirvjC37lXbTabNo3R4Tbt4=
=SUFA
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org