Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed yesterday.
Improve this question
One of web tools we intend to use requires docker for installation. Due to limitation in resources, however, the only way for us to deploy this tool is on a shared university php webserver with an associated MySQL database. My question is, can you somehow convert or even "compile" this docker-dependent tool to get some simple package, similar, for instance, to Wordpress? Indeed, as per my understanding, Wordpress development does require docker, while the final package for Wordpress installation does not.
Is this operation of docker-removal possible and is there a standardised workflow? The tool in question is located in the following repository.
I have tried to install the tool as is, being blocked by the lack of admin privileges and the absence of docker on the described university webserver. I have experience in setting up Wordpress, I would expect for my tool of interest to have a more sophisticated installation process (compared to the current 3 steps) without docker and, for instance, to also require manual connection to an SQL-database.
Please excuse me for my limited understanding and layman terms, I am sadly not coming from a computer science background.
Related
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 1 year ago.
Improve this question
What is advantage of using docker in local machine for running app?
And difference without using do docker.
Reproducibility. No more "works on my machine".
Furthermore, we can deploy all our dependencies (relational database, document-based database, graph-database, messaging-system, ....) through docker (e.g. through a docker-compose file and thus eases development.
Another advantage is that - in case we deploy to a container-based environment - we can use the exact same images used in production and thus improve dev-prod-parity.
There are a lot of advantages:
You can easily install few versions of different software without any collisions (e.g. 10 versions of MongoDB).
As previous commentator said - it creates isolated environment similar to your production (the only difference is the actual number of resources, such as CPU/GPU/RAM/etc.).
Easy setup for new developers (no need to manually install each separate tool and resolve issues with installations/configuration/etc.).
Ability to quickly deploy test environments, or new servers, or deploy this app on your brand new laptop)).
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I was going through Puppet and comparing it with Docker.
I came to know that Puppet is used for configuration management for scalable infrastructure. New VM's setup can be done with same configuration easily etc.
Seems that Docker is also capable of all these though in a different way.
Is docker replacing the configuration management tools like puppet, chef etc?
Please help me to understand.
Thanks in advance.
Unsure of if this question belongs here or not, but never the less, here is some source material that probable explains it better than me: http://cloudify.co/2014/10/30/Docker-cloud-orchestration-configuration-management.html
Docker operates in a different manner than Chef or Puppet. Docker is (with limited exceptions) a static system. Chef et. al. are dynamic in nature. If you seek to change a fleet of Docker provisioned services you would create a new Docker container, push it out and blow away your old ones.
Chef et. al. instead check frequently for state changes and when they occur they pull those changes down and converge. This leaves room for having parts of the server automated and some not (if its a difficult to manage portion, for instance, or for emergency repairs).
Of the two Docker is the stronger model in my opinion but even then you should have some well defined CM to create your docker images, such as serverless Chef, Ansible or other.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 6 years ago.
Improve this question
I'm new to docker. I just installed it and I have a question about this , it could be duplicated but I can't found a solution by searching all the forums.
Why it's better to use juste one service (apache, PHP, Mysql...) inside one container?
Because the whole point of Docker is to encapsulate a service within a single image, that you then clone to make instances of. You can clone multiple instances and trivially scale out an application - but it's rare that you need to clone every element of the application like that. It's much more useful to be able to widen your web tier, or your database tier separately.
But the major reason is - a container is an instance of an image. If you update your application, you need to build a new image. It's considerably more useful to be able to rebuild and restart subcomponents of the application, for all the reasons it's a nuisance to have to update your server to 'update'.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 2 years ago.
Improve this question
I'm new to Nix and quite excited about it (I've been using it so far for Haskell).
I'm planning to use it to deploy Php applications. However, how Nix deals with
Php packages (installed normally or with pear).
Working with PHP webapps generally requires several running services (php-fpm, httpd, mysqld, redis, etc). The answer depends on how you manage the services -- which, in turn, depends on whether you use:
(a) The full NixOS: NixOS provides a service-management layer - you edit a config file, twiddle some flags, and turn on the services. I haven't done this myself, and I think it needs a more pointed tutorial for folks coming from a PHP webdev background, but the system does exist.
(b) The crossplatform nix/nixpkgs: There does not appear to be a canonical service-management option here. nix basically just gives some binaries (php-fpm, mysqld, etc) which you can launch yourself. It's somewhat daunting for typical PHP developer.
Full disclosure: To try to improve the situation for crossplatform nix+PHP, I've written an example project locolamp. It won't help much with learning NixOS, but it may help get your toes wet with nix+php in cross-platform usage. See:
https://github.com/totten/locolamp
After spending a week trying to configure a LAMP platform and giving up (mainly because I couldn't make PHP send emails), I concluded that Nix is not ready for developping easily PHP application in production.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
Ok, this sounds like a bit of a rant, but I was wondering if there was a technical reason that Erlang doesn't have a proper package management system by default.
No major technical reason really. Just different needs as the classic way of setting up and installing erlang software is though applications. And some use releases added to that.
Often you see erlang software distributed completely self reliant. That is that it contains all the libraries and the virtual machine together in a package and not needing any sorts of external dependencies. You even see this in development versions of packages. The source tree of the Riak database for example has all dependent libraries in it.
This is not a bad idea like many coming from Ruby(like me) may think. This way each application is self reliant. As one of Erlang's main goals is to be the most reliable thing available it makes every sense in the world that each application can have it's own version of the library. Thus making sure one app does not make the other unstable.
Try rebar; it's a build system for erlang that includes a dependency management system. It doesn't have a central repository like gem does with rubygems.org, so you have to specify git urls. But, it does save you the trouble of having to download nested deps; it takes care of that itself.
And it sticks with Erlang's philosophy by keeping the downloaded deps inside your project directory rather then in a central system location; this is similar to bundler's deploy mode.