Link to home
Start Free TrialLog in
Avatar of projects
projects

asked on

Terminology and details; php to container

I have a rather simple php app which does nothing more than accept authenticated connections, then inserts data being sent into a db. Nothing more. No front end, no back end, just a few php files.

I need to convert this part into a container so that it can be more portable, more easily moved around, added into more servers without having to build complete Linux servers just for this task. For example, stick on on Amazon.

What I am asking for is terminology, possibly tools, links, leads. What do I need to look for when wanting to do this? Is there a term for converting a php app to a container? And, are there tools that already exist or is this something that will need to be programmed.
Avatar of Dave Baldwin
Dave Baldwin
Flag of United States of America image

If it is not hosted on a web server, how are you going to connect to it?  I have programs that turn PHP code into EXE files but they can't be used to accept external network connections especially on the same ports that are used for web servers.

Accepting external network requests requires a service that listens on a defined port.  The web server provides that for normal PHP apps.  For you to create a 'standalone' app, your app or program has to provide that service.  Then you have to allow it to connect thru the firewall.

While it is obviously do-able, it is a much bigger project to do it as a standalone app.
Avatar of projects
projects

ASKER

Yes, of course it needs a server but I am saying that the app or container would run on an amazon service, but they only need the app as a container.
In other words, no need to set up a full Linux box to run a container on a service like AWS.
??  I don't use AWS.  Isn't AWS a full web server of whatever kind you want?  Plus you need a database server and a database has to be set up.  I don't see how your 'container' makes anything easier.
Why do so many of my questions end up like this lately? They always get side tracked.
Yes, it needs a DB, yes, for our purposes, this would make it easier to deploy in different regions while the db would remain at a central location.

The point is to not need a full web server for a simple php app that could be stand alone running on AWS slices which could easily be expanded both in terms of resources and locations.
Assuming that AWS stands for Amazon Web Services, AWS is a full web server. So your assertion to run on AWS but not need a full web server is contradictory.

We need more information to determine what you're trying to accomplish. Sure, as Dave said, it's possible to make the app portable. All you need to do is avoid any relative paths or references to localhost. So long as the database user account has remote privileges, the app could be located on any web server. But in order to accept authenticated connections it will have to have network access. If the authenticated connections are from a browser, it will have to be a web server and it will have to support PHP.

So any web server with PHP support on the internet could host the app.
Are you perhaps looking for something like Vagrant?
https://www.vagrantup.com/

Usually used for development environments but basically you can create or download a vagrant image that includes whatever stack you want. The environment loads in a virtual machine that is linked to your code through the config files you create for the environment.
Why do so many of my questions end up like this lately?
I would say it is because you provide incomplete information.  Your question sounds like you want something 'easy' while it appears you have not considered the actual requirements.

When I read your question, my first response was how are you going to connect and where is the database.  If you knew those things, they should have been part of the original question.  To me, details like that are critically important to a project like this.
I'm with Dave; I don't quite understand the question either.  A more functional description with fewer technical details may be helpful.  It sounds to me like you want a publicly deployed PHP application with some kind of client authentication and a centralized database.  It sounds like the PHP app would (maybe) take the form of an API.  The part I don't understand is the need for a "stick" or other specialized tool for access to the PHP app.  What would prevent a browser from being a good way to access the PHP app?

In semi-related news, if you're considering Vagrant, you might also want to have a look at Bitnami stacks.
If you are looking only for a container and you are linux based then Docker (docker.com) might be a better option.
@Kim Walker
>Assuming that AWS stands for Amazon Web Services, AWS is a full web server.
>So your assertion to run on AWS but not need a full web server is contradictory.

I don't know much about Amazon services and they seem to offer multitudes of them so I am trying to find the terminology I need to learn in order to know what I am looking for.
It seems I've used the term AWS incorrectly.

>If the authenticated connections are from a browser, it will have to be a web server and it
>will have to support PHP. So any web server with PHP support on the internet could
>host the app.

Yes, web servers serve up php/html and other content but that's not what I'm asking.

@Dave Baldwin
>>    Why do so many of my questions end up like this lately?
>I would say it is because you provide incomplete information.  Your question sounds
>like you want something 'easy' while it appears you have not considered the actual >requirements.

What??? LOL.

>When I read your question, my first response was how are you going to connect and
>where is the database.

Why would that be your first question? I explained "a rather simple php app which does nothing more than accept authenticated connections, then inserts data being sent into a db".

This explains the situation now, There is no mystery. Whether the db is on the same box or on another box somewhere else makes no difference in this question.

>If you knew those things, they should have been part of the
>original question.  To me, details like that are critically important to a project like this.

Maybe too many 'experts' always make the assumption that someone asking a question has no clue. I didn't think I would have to add such details because they seem obvious based on having said the above.

I cannot always share that many details which is why I use this site, thinking that experts will immediately understand when you explain the basics, especially in this case where I explain the current situation.

In this case, I believe I provided the basic details needed.

"I have a rather simple php app which does nothing more than accept authenticated connections, then inserts data being sent into a db. Nothing more. No front end, no back end, just a few php files."

That should tell the story to practically anyone that currently, this is a simple *php* app running on a *web server* which accepts authenticated connections over a *network* which accepts data from the remote and inserts it into a database.

If someone called me on the phone and said the above, I would certainly understand the basics immediately. 'Ok, so, small php app, receives authenticated connections from remotes sending data to be inserted into a db. Got it'.

That explains what exists now. The question is asking *Amazon experts* for help and information on what Amazon might offer that could solve a problem.

The problem in more detail.

I have a small php app as explained above. I need to have this running in different regions in order to load balance and optimize this part of the project. The client receives data from many sources worldwide and one server in one data center is not enough. Setting up and maintaining full web servers all over the globe is not efficient and would take a lot of time and people.

Therefore, the php app mentioned above needs to be converted to something else, something more efficient for expanding it globally, where we don't have to set up full operating systems every time we want to fire up another location.

I know that building an app into a container means you take all of the required components and you basically build a 'container' which holds all of these components, a complete application I guess you'd call it. In fact, it doesn't have to remain a php app, it could be converted into something else since it's a pretty simple app.

Since many data centers support containers, my understanding is that instead of building and maintaining complete operating systems we could instead maintain our one container which we would upload/update on the various data centers that we would use and very quickly have a new location up and running.
 
Since I don't know much about Amazon services, I am asking what might I be looking for? I don't want to have web servers all over the place. I want to make things simpler. I am not sure what Amazon offers that would give us something like this, a slice, instances, where we can upload our app and simply add resources such as bandwidth, more slices, if they are even called that.

I don't know. I'm an old school guy that builds servers, networks so when we need more resources, I simply add more into the servers or I add more servers, or more bandwidth or set up load balancing, distribution, what ever it takes. I've no experience what so ever with companies such as Amazon and their amazingly large array of services so wanted to start by explaining what I have and what I need here.

Hope this helps.
greetings projects, , Not sure as any can be much help for u, but you may should take the time just to look and survey the offerings of the Amazon Web Services, which are extensive and varied, , since you seem to be mostly only concerned with what you call a "container" (there are several programming variations on that term) you can check out this strategy for an AWS container -
       https://aws.amazon.com/ecs/

as you seem to NEED a load balancing, distribution situation, AWS offers this in so many ways you may should find a price and capacity that suits you?

If you are stepping into the world of Amazon distributed services, you can get their
   "Developer Support plan"
to have their professionals hand hold you, and show you how to do what you need to do at -
     https://aws.amazon.com/premiumsupport/developer-support/


BUT you should make direct enquireries to the sales guys at Amazon services, and they are eagar to sell to you and they can get answers to your so very easy question that you ask here.
Load balancing and bandwidth on demand are part of the allure of the cloud.  Amazon Web Services is one of the cloud vendors.  Google, Dreamhost, Rackspace, Bluehost, and others offer cloud solutions.  Might be worth looking into this:
https://cloud.google.com/solutions/websites/
Thanks Ray, yes, I know they offer those things.

I have called a couple of vendors and since I don't have even any basic terminology for what I am looking for, they are eager to sell me all kinds of things that don't seem to be what I need.

I figured I'd ask here for some terminology based on what I am needing.

When talking about containers, it is simply a starting point. Other than knowing what they are in a basic sense, I'm not sure if this is what I'm looking for.

I am looking for a solution that can easily start at what ever size we need, in as many regions as we need, easily being able to turn up the switch as we need more resources without having to maintain entire operating systems for this very basic function.
It sounds to me like you're thinking about this in an "old-school" frame of mind, where you had to install and provision servers.  We don't have to do that any more with cloud computing; it's more of a capacity-on-demand model these days.  The cloud provider handles the setup, distributed computing, and load balancing.

But that said, I'm still missing some pieces of the puzzle.  Can you please tell me (or give me a link that shows) what a "container" is in your context.  It's not a term I'm familiar with.  I can find information about Docker, but it sounds at first blush to be a complicating factor for a single simple PHP app.

Can you please tell us a little more about your "authentication?"  Is this a handshake like OAuth or is it more like an API key embedded in the request?

Also, when you speak of no front-end or back-end, I'm confused.  I think of a front-end as a "view" in the MVC design, and the back end as the "model" where the data is stored.  In any case, all of this internet stuff uses the HTTP protocol, and that has some basic communications requirements.  And whether you use the MVC design or not, you need to store and retrieve data.  If you see these things differently please help me get a better understanding of the way you see them.  It may just be a matter of getting to common terminology.  Maybe if we clarify the terms we can get to a better understanding.

If you're looking to make the PHP app more efficient, that might not be necessary.  Much of Google, all of Digg, parts of Yahoo and nearly all of Facebook are PHP machines.  Obviously these services are load-balanced, but a more common design at scale is to denormalize your databases and throw hardware at the speed problems.  IIRC Facebook has open-sourced their implementation of HHVM, and PHP7 is much faster than the old versions.
Here we go, I've put together a very basic diagram.

This is a very typical application. We have servers installed in different countries. The problem is that we have to maintain all those servers just to run a small php app that remotes can connect to in order to send a little data.

User generated image
1: remote php (or potentially other protocol) connects to a region which is closest to it rather than all connections having to go to the USA. remote php connections are authenticated https connections sending data to the receiver, for lack of better word, currently a simple php app on the server side.

2: lets say Amazon for the sake of argument and we have instances (or what ever they are called since I am not sure yet, which is my question) in various regions so that the remotes do not have to connect directly to the USA, and distributing this part of the task which is remotes sending data to a central db.

3: A central DB somewhere on the Internet which the Amazon instances would communicate with, updating the DB.

4: The end web server farm which provides the user interface and access to all of the data.

The question is related only to part #2, nothing else. Rather than having to maintain web servers/operating systems all over the place, I'd like to find a different solution, something we could upload to a service such as Amazon, maintaining just one copy and updating all of the amazon instances as needed when we change some code.

We don't need a full operating system for the #2 part of the setup. We are running a whole server for nothing more than a few php pages that the remotes can connect to.
Ray, I know all of that which is why I am interested in this for part of the overall app. I don't need a service for the entire setup, only for the #2 part I am showing above.

Authentication simply meaning an https connection using a name/password.

No front end, no back end meaning there is no user interface. It is simply an app that sends data to a php app on the server. There is no interface for a user to see using a web browser, there is no admin back end, it's simply a small php app that receives some data.
You probably should have started with that diagram.  And I'm with Ray, I don't know what you mean by 'container'.  An https connection strongly implies a web server, that's where they are used.  I don't know of any other place you can make an https connection.

Shared hosting is available for less than $10 a month although you may have to search for one that allows you to connect to external databases.  But you can connect thru another PHP program on the "Centralized DB server".  Of course, that too would require another web server supporting PHP.

And there is no 'PHP protocol'.  PHP will use various network protocols but if you're going to use HTTPS, then it's going to be standard HTML forms submission (to a web server) which does not need a visible form.  I do that all the time.
About "an https connection":  It requires an SSL/TLS certificate which also requires a unique domain name and a unique IP address.
so that the remotes do not have to connect directly to the USA,
This seems to imply that there is a cost or penalty to connecting to a USA server; that such a connection is to be avoided.  It's true that for very, very high activity web sites a CDN might make sense, but that's a thing for outbound volume.  If I'm sending small amounts of data to a server, I don't really have to care where the server(s) are located.  Even if I'm sending megabytes to the server, the physical location is not really an issue in my experience.  The internet is pretty fast everywhere.

Can you tell us how many daily messages are required, and what is the volume of each message?  

And can you please clarify what you mean by a "php connection?"  PHP is a scripting language that runs on the web server.  PHP is typically started in response to an HTTP(S) request (often from a browser, but there can be other kinds of client machines) and PHP receives the request data.  Using the request data PHP may update the data model (usually a database) and produce a response document (often a web page, but sometimes just an HTTP response code).

This is the way I envision an application working.  In this diagram, PHP runs on server-1 and server-2.  If there is not an overwhelming amount of request / response traffic, it might be possible to dispense with the load balancer, and just use one of the servers.  A big powerful server is not very expensive these days, and AWS or Google or whoever you get the cloud from probably buys them by the truckload anyway.
User generated image
ALL of the information you are all giving me is useless.
You keep asking what I mean by container and I've already explained that.
You keep explaining basic networking to me and I've explained that's not what I'm asking about.

I am digging for information to better understand what terminology to use so telling me I'm not using the right term is lame.

Done.
Gee, thanks.  It's always a pleasure to do unpaid work  for people who misuse common terms of art and then call me "lame" when I try to discern the true nature of their awkward questions!  

Please be sure to let us know how everything worked out.  Kim, Julian, Dave, and I can't wait to hear!

Best of luck with your project, ~Ray
Unpaid work? Try answering the actual question instead of going all over the place, talking about basic things that anyone who works on servers already understands.
It is silly to keep asking me to use the correct terms when that is what my question is about to begin with. Talk about going in circles.

You're wasting my time also by doing this. I'm sure I'll find the answer I'm looking for without ee.
Did you see my earlier post on the reference to docker (docker.com)?

Refer to docs on Doccker on AWS

https://aws.amazon.com/docker/

Docker is one of the most popular container platforms out there - if this is not what you meant by container then I too am going to have join the ranks of my colleagues and withdraw from the discussion.
Yes, I saw your suggestion and am aware of Docker and is why I mentioned containers as it's all I know about at this stage. I am asking about terminology, what else I should be looking for as I don't know what else exists that I should be looking into.

This question has gone way off track and it's interesting how someone mentions I added too much information while another says too little. I've tried posting in all kinds of different ways on this site. Never quite sure how to post when it's something I am needing to learn about to begin with so I can post another more specific question once I better understand what I'm asking.

This question is useless at this point.
I should be looking for as I don't know what else exists that I should be looking into.
I think all the bases have been covered.
There is the pure virtualisation route - Vagrant is an example of a solution in this space.
Containers is an alternative solution.

The two are similar in their purpose but differ in their implementation - the latter running natively in the OS kernel - the other in a virtual compartmentalised space on top of the kernel.

Having looked at your diagram I am wondering if the benefits you might gain by decentralising your touch points will not be negated by having a centralised database. Should you not be considering a decentralised database setup as well?
I didn't want to get into the minutia but yes, there are databases all over the place, all synced up.
The bases are sort of covered. I'm already aware of containers and mentioned that as a possible solution but am asking for others. I used the term container and converting to container because it's all I know.

What I was asking about are other alternatives, solutions which don't require a full operating system/web server to serve up only a handful of php pages. The app could even be converted to something else, doesn't have to be php but that is the problem, I do not know what is out there which doesn't require full web servers to serve up a small app that is used to accept data and insert that into a db.
Ok, I understand.

The container solution allows you to "package" your app with all its dependencies - which is an acceptable solution.

Another option is to potentially look at using something like NodeJS - not really solving anything in the way of a server - it effectively fills the gap Apache would leave if you removed the latter - but it does allow for a more lightweight implementation. Drawbacks
a) Learning a new framework
b) Recoding PHP scripts in Javascript

Not sure it would be a plus. Right now it seems something like Docker would be your best bet.
@Julian, converting the php app to something else would be fine. We can reprogram as needed on either side, the remote and the php app to make them work together. Parts 1 and 2 in the basic diagram I uploaded.

Mainly, I am wanting to avoid needing a full web server for part 1 ad 2. Think of it as a client/server app over the Internet. You have a client that wants to send data and you need a server side to receive that data and to insert it into a db.

Without getting into all of the little details about how web servers work and that they need network connections such as some of the responses have been, getting past those things, what options might there be with offerings by Amazon and others for example which would allow us to have 'slices' or 'instances' which we can quickly and easily turn up as needed without needing to maintain complete operating systems/web servers.

That is what I've been trying to explain. We need to get past the basics of serving up pages. I'm trying to learn more about what options exist which would not require us to maintain lots of web servers for simply a small client/server app. Meaning, only the part #2 in the basic diagram I've shown.

I know that serving up anything that is web server based requires web servers. What I am asking is if there are alternatives that don't require full web servers for such a small app as what I am showing.

I wish I already knew some terms for what I'm looking for but that is the challenge of this question, I don't know any terms yet. I've read countless articles and have seen many documents but all of them are talking about web services. I had a ton of bookmarks and links to possible solutions but they were lost when an upgrade was done in error. There are other protocols out there which don't require web servers, which allow client/server type applications but the part I'm not clear on also is if those could be supported by companies like Amazon.
I think some of the confusion comes from the fact that you are asking what is offered by companies like Amazon - when in fact their cloud services are precisely geared to doing just this - dynamic cloud provisioning. This is basically the on demand allocation of VM resources (or similar) to meet a particular requirement.

You create the image that contains all the code / dependencies that you need - that becomes the template so to speak. The cloud service provider can then spawn as many copies of that VM as you may need - where ever you may need it

I think if you look up dynamic provisioning you might find what you are looking for.

The container / VM discussion is really about the packaging of your application rather than the provisioning of it.
@Julian, now we're getting somewhere!

Thank you, you understand what I am trying to find out. Now, let's expand on this.
What you've mentioned are basically web services and this part I already understand but we're on track now.

Let's just step away from web services and talk about client/server methods that do not use web services but some other protocols.
I don't know if that even exists in the cloud however.

I found this in another question on another web site but it explains exactly what I am asking.

\\
"web" applications imply a browser or curl is the client
Client/Server apps imply a custom client app. Think Outlook hooked up to exchange, while it may use the web to connect, it is its own client to the exchange server.
//

Another example of a client/server app might be Iperf or any other service which isn't web based but having it's own protocol/ports, etc.
Imagine if you ran an Iperf server. You would not need a web server, you would barely need much of an operating system, you would simply need something which can host the Iperf server side of this client/server application. You could build a very purpose built system without much on it, no need for a whole LAMP setup and the many parts that are needed for that.

I am not sure if an Iperf setup can actually be considered a client/server when it comes to correct terminology.
Just swap out the Web Server for an Application Server and the Web Browser for a Client Application.

In my case, as explained in my question which no one seems to understand, I said there was no front or back end. Think about a VoIP phone that sends some usage data back to some server on the net which is in turn stored into a database and you have exactly what I mean. No need for a front end and no need for a back end, meaning no need to display anything, such as on a browser and no need for a back end meaning no need for a management interface, this is a simple send/receive setup.

I hope this further explains what I am asking about which is probably more like what kinds of 'application' services could cloud computing offer which could be as flexible as turning up resources as needed for web services.
I don't know if that even exists in the cloud however.
What exists in the cloud is the potential to run whatever code you cobble together - the cloud is just online CPU / Storage - what you do with it is up to you. Additional services such as provisioning and load balancing are provided as services by Cloud Service Providers - you use those depending on your requirements.

As to the rest of your comment. Anything that listens on an IP socket can be considered a service. A web server by default listens on port 80 and processes requests using the HTTP protocol. You can create your own service and have it listen on a port of your choosing and you can define exactly how you want to communicate with that service. However, the reason we fall back to Apache and NodeJs and similar is that all the intricacies of socket programming for a service that has to potentially service multiple simultaneous connections are already solved for us - allowing us to focus on what needs to be done rather than re-inventing the wheel.

If you are trying to remove the LAMP components out of the package then lets look at that
Linux
Apache
Mysql
PHP

Linux - the OS - has to be there
MySQL - you said your DB is already sorted

That leaves PHP and Apache - if you eliminate those you still need something that is going to listen on a socket and process incoming requests. In terms of development time you are looking at a lot more hours.
However, in the end it comes down to complexity - if your app is really as simple as listen extract send to database and go back to listening then it might be worth spending some time to create a binary that does all that for you - one application that handles incoming requests and sends data to the database. There is enough sample code out there to give you a scaffold to start with - if you look for lightweight open source HTTP server you should find many examples. You could use that code as a base, modify it to specifically what you want and then just distribute the binary.

Let's consider the two scenarios

Option 1: LAMP + your PHP script. You build an image with your required dependencies (LAMP etc) you then use that image in your provisioning solution

Option 2: You build a custom app - install it on a Linux build with MySQL drivers to facilitate the database connection and then use that image in your provisioning solution.

In both cases you still have to configure and build an image to use - the first one might take a bit more time in terms of installation and might have a slightly larger footprint but the server code and DB connect code will be tried and tested.

In the second instance you might have a slightly shorter (once off) build and configure time but you will spend more time on the development of the application.

At the end of the day - if you are going with a provisioning system - you will end up with an image in each case - the only difference is the dev time on the second will have taken more time but in terms of the service offered by each they will be functionally the same.

I hope I am making clear what I mean - if not please feel free to post back with more questions.

In short - the way I see it - it's swings and roundabouts - with the advantage tipping in favour of the LAMP solution (tried and tested - works as required).
@Julian

>What exists in the cloud is the potential to run whatever code you cobble together - the cloud is just online CPU / Storage - what you
>do with it is up to you. Additional services such as provisioning and load balancing are provided as services by Cloud Service
>Providers - you use those depending on your requirements.

Yes, of course they will sell you what ever you'd like to pay for but to keep things simple, not requiring anything all that unique, I am hoping to find services they already offer. For example, if they offer a minimal server slice where I could run for example that Iperf test I was telling you about, that could work. I've no idea what that might be called however. Is that a server since it is not web services.

I think your last reply explains it all and explains that I am not actually looking for any new terminology after all. I just needed to better understand how such services work.

In our case, doing the second will be the answer. We've got great programmers but I use this site to try and gather the information I need in order to sit down and have these conversations. If I don't know what I am talking about, I will be wasting everyone's time which is why I try to gather those details using this site.

The following clearly explains what I was missing and it turns out, I wasn't actually missing anything. The information on the sites I've looked at is simply a little overly technical for people that are new to such services.

>In both cases you still have to configure and build an image to use - the first one might take a bit more time in terms of
>installation and might have a slightly larger footprint but the server code and DB connect code will be tried and tested.

>In the second instance you might have a slightly shorter (once off) build and configure time but you will spend more time
>on the development of the application.

>At the end of the day - if you are going with a provisioning system - you will end up with an image in each case - the only difference
>is the dev time on the second will have taken more time but in terms of the service offered by each they will be functionally the same.

So, there is no special service that handles simply a 'container' for example. You put everything you need into the container but you still need a simple server instance to run it. The instance can be set up with everything wanted on a server such as LAMP or only the specific parts needed if we build our own app using custom ports, not http/https based.

From there, the instance is the part that I'm 100% clear on yet.

I think what you're explaining is that once we have this instance and have what ever we want running on it, we can simply turn up the power so to speak, adding bandwidth, storage, etc etc if needed.

And finally, like vm for example, we can copy this to other data centers if we need to.

Am I understanding it all now?
ASKER CERTIFIED SOLUTION
Avatar of Julian Hansen
Julian Hansen
Flag of South Africa image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
I would like to cancel the deletion of this question and award the solution to @Julian who took the time to understand what I was asking.
Experts should take more time to read the questions and not automatically think that the OP has no clue.
This ends up being a very long winded question which most won't bother reading but if they read to the end, will find the answers as I have. Thanks.
Thank you and good luck with your project.
Additional info,

I had a discussion with one of the Amazon product execs here and he was saying that while they support Docker it is not a great solution because of the difficulty to manage.

His take was a better option was to look at Amazon's Lambda functionality (https://aws.amazon.com/lambda/details/) which is basically hosted functionality where you get billed only for the CPU time you use with a generous free set of requests. They support Node.js, Ruby and Python currently. I have no personal experience with this but from what he was saying this looks like it might also be an option for you to consider.