We have been testing with Platform.sh this weekend, which uses debian as its OS. The deployment of the application was easy, until we started testing some of the core functionalities like creating a PDF.
The PDF is generated using wkhtmltopdf, which has different binaries depending on OS. Our own platform consists of CentOS7 machines, so we let composer install the Centos7 specific package: https://github.com/rvanlaak/wkhtmltopdf-amd64-centos7 For Debian this package is needed: https://github.com/h4cc/wkhtmltopdf-amd64
So basically the problem is the inconsistency in plaform. Saw that composer allows you to define specific versions for PHP and extensions, but config.platform unfortunately can not solve this problem.
Unfortunately the following hooks did resolve into a deployment error too:
composer remove rvanlaak/wkhtmltopdf-amd64-centos7 --no-update
composer require h4cc/wkhtmltopdf-amd64:~0.12 --no-update
composer update
As we can not choose the OS on platform.sh, how can we let composer check for a specific OS?
Related
I am trying to build docker image on Apple M1 chip Mac and one of the steps include installing postgresql-client-10 package. The base image is ruby-2.6.5-stretch and I have added file repository configuration and repo signing key as listed on postgresql documentation page for Debian. In the last step, when I am trying to install a specific version postgresql-client-10, the build errors out because it is not able to find this package.
This was working fine on AMD Debian Stretch build but not finding this client on ARM Debian stretch. If I install postgresql-client (without specifying version), it installs version 9. Is it possible that the client is not available for versions 9 and above? Where can I get the list of available client versions for postgresql based on Debian releases?
There's one more caveat, when I try to install it on Buster release, the installation is successful but since I need to have libproj12 (due to gem dependency), libproj.so.12 file is not found. Since the libproj package list for version 12 shows only stretch release, I think I am confined to using stretch release only and have to make it work for postgresql 10.
i am facing problem while setting up the magento server on Centos7 i have php 7.3 install in my centos ec2 instance
installed php 7.3.5, also tried to update composer using $composer update command it doesn't work
composer install
Magento 2 does not support php 7.3 as of yet. A significant numer of core modules specify the php versions they will allow. You will need to change your php version. See this link for the supported versions. https://devdocs.magento.com/guides/v2.3/install-gde/system-requirements-tech.html
I am working on ubuntu 16.04 with PHP version 5.5 now I want to use SOAP library in it.
I have already installed php-soap package(with ref. How do I enable --enable-soap in php on linux?) and tried to enable it. but it won't works for me anyway.
By searching I found php soap package are available for PHP version 5.6, 7.0, 7.1.but am working on PHP version 5.5 and in situation that I can't change PHP version of my system.
Any way or suggestion to install soap for PHP5.5 would be great help.
The SOAP package is available for all versions of PHP since at least 4 something. There are two options on how to install/enable it depending on the way your PHP was installed initially.
If your PHP was installed via the distribution's package manager you just have to install the package php-soap. On your Ubuntu this should be:
sudo apt-get install php-soap
If your PHP was compiled on your machine you will have to compile it again passing in the switch --enable-soap .This switch could differ depending on your PHP verison. Check the documentation of make in PHP's source if this is the case.
I would like to know how to install multiple vendors into one project using composer. E.g I would like to install Paypal SDK and Stripe SDK into my project.
How do I go about this, and how would the folder structure look like?
You can install as many dependencies as you wish using Composer. For instance, to install both Paypal's and Stripe's PHP libraries, you'd run these commands:
composer require "paypal/rest-api-sdk-php:*"
composer require stripe/stripe-php
Afterwards, both libraries would be installed in the vendor directory, and both would be automatically included in your code when you load dependencies with:
require_once("vendor/autoload.php");
What are the pros and cons of using Debian packages to deploy a web application as opposed to using Fabric? I have only ever used Debian packages.
I'm also interested in hearing about problems you've bumped into when using Fabric and you wished you had used Debian packages.
Debian
It is a Package Manager. It allows user to manage packages through various programs like dpkg or apt on a system.
What it does for you :
builds package from source
handles package dependencies, package versions
installs, updates and removes programs on a system
works at low level, compiled binaries maybe system specific (i386, amd64)
Cons :
To deploy the application the configuration must be provided in your package, or some configuration has to be used as default
Different binaries for systems with different architecture
Fabric
It is a Python library and command-line tool for streamlining the use of SSH for application deployment or systems administration tasks.
What it does for you :
configure your system
execute commands on local/remote server (systems administration)
deploy your application, do rollbacks, mainly automate deployment through a script
works on a higher level, does not depend on system architecture but on OS and package manager
How do you use pip, virtualenv and Fabric to handle deployment?
Cons:
It cannot replace package manager on a system, it manages packages on top of it
You should know the system, commands folders specific to your package manager / OS
Update
I was already familiar with Debian when Fabric came. So Debian has stayed as my preferable tool. Why I use Fabric, it eases deployment of applications and is handy tool for developers. Here are some reasons why I would use Debian over Fabric:
When I am not going into production, still developing and testing stuff. Debian is suitable most of the time, when code is being added/modified. Fabric just eases the transition from development to production.
Sometimes if I deploy application on my machine only, Fabric seems overkill. If deployment does not involve many machines, requires several dependencies, I would stick to Debian.
When rollback, or undoing is not an option. Fabric will simply execute your commands safe or not, if you are not adept at handling system errors/exceptions, try it somewhere before using Fabric. (Debian is part of system so have to use Debian and other system tools)