In lieu of manually setting up my dotfiles (.bashrc, .inputrc, .vim & .vimrc etc) inside the docker container that DDEV creates... isn't there a way to automatically do this from the ddev config? I swear I saw this somewhere (maybe a blog post?) and I've been looking through https://ddev.readthedocs.io and websearching but can't find it described anywhere. Do I need to do docker cp ... or is there a ddev way?
Yes, you can provide custom in-web-container configuration using homeadditions, see docs. You can either add new configuration (anything you want in your home directory) per-project (by putting in your project's .ddev/homeadditions) or globally (by putting in the global ~/.ddev/homeadditions).
There's a blog example of doing this (from before you could do it globally in v1.15+) showing setting up oh-my-zsh, https://www.ddev.com/ddev-local/oh-my-zsh-using-custom-commands-and-other-goodies-to-add-to-ddev/
Related
We are a group of developers that work on multiple ddev projects. Some of these projects have a "." in their name, which by now breaks the PhpStorm integration.
Is there an easy way to rename a project and allow all other developers to tell ddev (after they pulled the new ddev config.yaml), what the previous project name was, so data (like database) could be migrated?
Please use the instructions in the DDEV FAQ "How can I change the name of a project?"
Use this process:
Export the database of the project: ddev export-db --file=/path/to/db.sql.gz
ddev delete . By default this will make a snapshot, which is a nice safety valve.
Rename the project, ddev config --project-name=<new_name>
ddev start
ddev import-db --src=/path/to/db.sql.gz
I have several projects where I use ddev. I want to configure bash-scripts and aliases like
alias ll="ls -lh"
for all projects. How can I do this?
My ddev Version is 1.14.2 and I am on a MAC with Bash 5.0.11 configured on my terminal.
I know if I use .ddev/homeadditions/.bash_aliases I have all aliases, which I configure in .bash_aliases, but I don't want to configure it again and again for each project.
DRUD did it. In Version 1.15 you can now add eg. global aliases or whatever you like, that matches .bash_profile .profile or other dotfiles in the home directory.
You just have to move or copy the file:
~/.ddev/homeadditions/bash_aliases.example to ~/.ddev/homeadditions/.bash_aliases
and add your aliasses there.
Now, if your container already runs, use ddev restart to "copy" the global aliasfile to the specific container.
If you need functions you can use that file too, like:
function test() {
clear
echo "Some text"
ls -lha
}
Thanks to #rfay
I am trying to debug an application I have deployed to google cloud app engine. Reading the docs, I figured out that in order to do so I have to enter the debug mode using
gcloud app --project [Project ID] instances enable-debug
afterwards I am able to SSH into my instance and access root. Now I would like to edit some of the files. However, trying to use vim or nano does not seem to work.
Is there a way to edit those files without re-deploying the entire app?
Once you SSH into the App Engine instance and open a shell into the Docker container, you'll need to download the package list before installing nano or vim:
apt-get update && apt-get install nano
Then you can edit your app's files (which are in /app):
nano composer.json
The deployed app runs live code. It is not generally feasible to edit it. Moreover, changes made to the running container are not permanent; in fact they and are lost at the first re-start.
You may find some information on the Debugging an Instance page.
Unrelated to the above, an actual command-line editor is offered in the cloud shell.
Hello there we am currently developing a Laravel application. I want all my team members to work locally so we decided to use Docker for our local development environment. I did a little research and there is a project called laradock. After installing it I am supposed to go to http://localhost and the project should run. But I get this:
I am using apache2 and mysql
tl;dr
Go to ./laradock/.env and search for APACHE_DOCUMENT_ROOT then edit that line to this:
APACHE_DOCUMENT_ROOT=/var/www/public
Things to do after the change
For this change to take effect, you have to:
Rebuild the container: docker-compose build apache2
Restart the containers: docker-compose up
Explanation
As mentioned by simonvomeyser on GitHub this is a recent addition which had the same effect as rodion.arr's solution but this way you can leave the original config files untouched and use the .env file to store all your project related configurations. Obviously, since this is a docker config change, you have to rebuild and restart your container, as rodion-arr and 9bits ponted it out in the same thread.
Check you apache configuration (in my case [laradock_folder]/apache2/sites/default.apache.conf file).
You should have DocumentRoot /var/www/public/.
I suppose you have /var/www/ instead
We are using spring-boot with the embedded launcher-script in service mode, to have daemonized/init.d behavior.
We however do not have an /etc/init.d symlink to the spring-boot jar as that would require using sudo. we avoid sudo to pass a profile-environmental like -Dspring.profiles.active=$APP_PROFILE in the JAVA_OPTS
(this won't work when started via sudo but defined in /home/appuser/.bashrc (?) )
We have this directory-layout with some indirections. basically app.jar => current/app.jar => build-xx/app.jar
appuser#host:~/apps/services$ ls
app.jar -> /home/appuser/apps/services/current/services-1.0-SNAPSHOT.jar
current -> /home/appuser/apps/services/services-1298
services-1298
When starting the application with app.jar start the launch-script generates an additional pid-subdirectory in the pid-folder based on the "identity" of the program. For us this can look like this:
/home/appuser/apps/services/run/services-1.0-SNAPSHOT_homeappuserappsservicesservices-1298/services.pid
Unlike when used with an symlinked /etc/init.d which gets special treatment and the pid-subdir services-1.0-SNAPSHOT_homeappuserappsservicesservices-1298 is omitted/stays stable.
This dynamic pid-subdir makes it very hard for us to check the daemon's status or start/stop during deployment because you have to always get the sequence right and nobody is stopping you from starting a process twice (the old instance and now a new instance with a new identity-subdir).
So, does anyone know why this pid-subdir-identity stuff must exist and what would be our best way to deal with it?
Do we have a bad setup?
Any advice appreciated.
You can control the identity by using the APP_NAME environment variable.
I'd recommend configuring your service's environment variables using a .conf file next to the jar file. For example, if your app is called app.jar, you conf file should be named app.conf and be placed in the same directory as the jar. You can then configure APP_NAME and JAVA_OPTS etc for your application. This should allow you to use init.d if you so wish.