Re: APEX externally available question

Well, we have a (probably?) smaller, and (certanly!) less sophisticated solution.

We are 100% on AWS EC2. (Elaastic Compute Cloud, think VMs in the cloud.)

We have a VPC (Virtual Private Cloud), that has both public and private subnets. All instances (VMs) get a private IP address, and, if you launch into a public subnet, that instance will also get a public IP. All databases are in private subnets, so no access to them from the outside. We have two web servers, running Glassfish and Apache, one in a public subnet (for production) and one in a private subnet (for dev/test). Each server is configured with Glassfish (yes, I know the latest versions of APEX have deprecated Glassfish, we are looking to move to Tomcat) and Apache. In some cases, we wanted a single Glassfish domain to support SSL connections for multiple domains. This was not possible with Glassfish alone. So, I installed Apache, which can easily support SSL for multiple domains, and use it as a front end, and talk to Glassfish via JK Listener.

It all works pretty well.

Upcoming tasks:

1.) Move from Glassfish to Tomcat. (I don't anticipate too much trouble here.)
2.) How to do load balancing and/or failover on AWS? (I know there are solutions, I just need to study up.)

-Mark

On Wed, Jun 19, 2019 at 2:58 AM Tim Hall <tim_at_oracle-base.com> wrote:

> What we do:
>
> - We have load balancers (F5 Big IP) that act as a proxy (
> my-app.example.com -> server1.example.com) and also provides SSL
> Termination (the real certificates are on the load balancer). It then
> re-encrypts traffic to send to the actual server. The actual server (docker
> container) just uses a self-signed certificate, because it's internal
> traffic only. The load balancer is in a "web zone" of the network.
> - Each functional area (roughly per database) has its own Tomcat+ORDS
> running inside a Docker Container. Each container is exposed on a different
> port. This sits in an "application server" network zone. A real firewall
> provides point-to-point rules, as well as the local firewall on the servers
> (that host the containers). This means a specific alias is DNSed to a
> specific VIP on the load balancers, which is routed to the relevant pool of
> servers. Comms from the load balancer use a specific SNAT per service
> (sometimes groups of services), which can talk to a specific port on the
> destination server(s). There is no cross-site-scripting possible.
> - Connections from Tomcat+ORDS to the database use Native Network
> Encryption. The databases are kept in a separate database zone of the
> network.
>
> The net result, assuming we've not made mistakes of course :), is that any
> specific alias "my-app.example.com" can be made available externally,
> campus/company only or available to individuals without allowing access to
> other services. In ORDS is pretty lightweight, so we can pile a bunch of
> these containers on each server.
>
> We *never* allow direct access to any application server, and rarely allow
> direct access to a web server. It always goes via a load balancer, even if
> there is no load balancing required. It just makes certificate management,
> proxying and error management a lot easier to do it that way.
>
> I'm sure people will come up with a bunch of different solutions, but
> that's what we do. :)
>
> Cheers
>
> Tim...
>
> On Tue, Jun 18, 2019 at 6:43 PM Jeff Chirco <backseatdba_at_gmail.com> wrote:
>
>> We are working on getting our first APEX application up and running with
>> Tomcat/ORDS running on a separate server from the database. The database
>> that this runs on is a multi-purpose database and we are planning on having
>> many different APEX applications in it. Some we will want to have
>> externally available from our network while others we only want to be
>> accessible from inside our network. What are some suggestions to achieve
>> this? Just let the network guys create rules if this URL then allow or
>> not allow? Or something better?
>>
>> Thanks,
>> Jeff
>>
>

--
http://www.freelists.org/webpage/oracle-l