We are currently running Apigility and a ZF2 application on our IBM i using ZendServer and php 5.6. We have just completed our conversion of the Apigility project to API-Tools so that we can run it under “Community” php (not ZendServer) and php 7.4. We have around 8 different APIs with about 80 or so web services.
From the development side, it is all in one project. But for execution, each API is in its own folder (with its own endpoint)
For deployment under Apigility, we’d create a zip package for a specific API and then just expand it into the corresponding deployment directory. But we are having a problem with this in API-Tools. Even though we are running API-Tools under a “native” instance of php 7.5, when ZF-Deploy does shell_exec(), it is picking up the 5.6 version of php from the global path and we get errors. We can’t change the global path because we still have the ZF2 application running under ZendServer 6/php 5.6.
Question: Is there a way that we can point ZF-Deploy to the same version of php (and config files) that API-Tools is using?
Question: Is there a better way for us to deploy API-Tools?
Heyo,
| dickdono
May 10 |
We are currently running Apigility and a ZF2 application on our IBM i using ZendServer and php 5.6. We have just completed our conversion of the Apigility project to API-Tools so that we can run it under “Community” php (not ZendServer) and php 7.4. We have around 8 different APIs with about 80 or so web services.
From the development side, it is all in one project. But for execution, each API is in its own folder (with its own endpoint)
For deployment under Apigility, we’d create a zip package for a specific API and then just expand it into the corresponding deployment directory. But we are having a problem with this in API-Tools. Even though we are running API-Tools under a “native” instance of php 7.5, when ZF-Deploy does shell_exec(), it is picking up the 5.6 version of php from the global path and we get errors. We can’t change the global path because we still have the ZF2 application running under ZendServer 6/php 5.6.
Question: Is there a way that we can point ZF-Deploy to the same version of php (and config files) that API-Tools is using?
Question: Is there a better way for us to deploy API-Tools?
I had to search what ZF-Deploy is - just noticed that it’s an old and now abandoned package: https://github.com/zfcampus/zf-deploy#repository-abandoned-2019-12-31
In general, do you need to run more than one application on the same server? In this time/age, isn’t it easier to package your app as a small docker container and run it somewhere?
As someone that had to work with IBMi too, my endorsement is to put effort in migrating away from it when possible, rather than fighting a long-term uphill battle in trying to run anything new on it.
My bad… It is not using ZF-Deploy, it is using api-tools-admin. But the issue is the same, it uses shell_exec() and picks up the wrong version of php.
As for leaving the IBM i, it’s not happening: rock-solid database, incredible scalability, and secure as they come. Not to mention, we get to take advantage of decades-tested custom code that doesn’t have to be changed/reviewed every there is a OS or language version upgrade.
| dickdono
May 10 |
My bad… It is not using ZF-Deploy, it is using api-tools-admin. But the issue is the same, it uses shell_exec() and picks up the wrong version of php.
I would suggest opening an issue directly against the affected repository: switching out the fragment can be easily done, once correctly identified.
As for leaving the IBM i, it’s not happening: rock-solid database,
You can connect to it from elsewhere: DB machine != Webserver machine. If you really need to use DB2, you can keep doing so.
incredibleee scalability,
Eh, not really, especially if you need to phone IBM for spinning up a new box
Secure as they come.
Mostly security by obscurity, since nobody knows how to connect to one 
Nott to mention, we get to take advantage of decades-tested custom code that doesn’t have to be changed/reviewed every there is a OS or language version upgrade.
Also here: mostly because unmaintained
Sorry, that’s really just snark coming from having had to work with those boxes: don’t really understand how they built an ecosystem around lies.
From your 5250, open a qshell or qp2term or even ssh into your box. I assume that, when you do a php -v, you will get back 5.6, which in this case is the version your path is set to (/usr/local/php/…).
You could try switching the default version to your 7.x install (should be a symbolic link).