Blog Details
Blog Post Actions
Related
Recommended

Developing using Docker - Office Hours Recap!

Matt Marum
2 minute read time

On Dec 6th, we held our monthly office hours session on doing local Sugar development using Docker containers. A sort of continuation from our session last month on using Demo Builder for development.

Our own   was the expert this time around. He has extensive experience with Docker and with helping developers in our community get up and running with local Sugar development environments. Thanks Rafa!

Session Highlights

Introduction to SugarDockerized

SugarDockerized is a great resource to help developers get a working local development environment of Sugar up and running quickly and easily.   gave a live demonstration of building a local development environment from scratch - from installing Docker Desktop to downloading and starting the containers, to installing and testing Sugar running on his local machine.

Working with fresh installs and SugarCloud backups

Rafael also demonstrated how you can do a fresh install using one of our Developer Builds  or a Sugar Enterprise downloads for doing add-on development.

Or how you can take a back-up from a SugarCloud and run it locally in your Docker container, with all the data intact, so you can debug tricky issues or develop customizations for a SugarCloud instance.

Session Recording 

This session was recorded on December 6th. Here is the recording and slides.

Let us know how we are doing!  

We want our Developer Office Hours sessions to be relevant and valuable. Please provide feedback so we can continue to improve and better serve you!  

Share your feedback with this short survey.  

Next Session Sign-Up  

We are skipping January 2024. The next session will be on February 7th, 2024.

Please register for the Office Hours series so you don’t miss a session.

Developer Office Hours are (typically) held on the first Wednesday of every month at 10 a.m. ET / 7 a.m. PT. 

Parents

  • Hi guys.

    Dear  I run the SugarDockerizer project on Arch Linux. I have had some problems with the script to restore oncloud backups. When I try to move the database to the mysql container, it always tells me that the database is corrupt.

    I believe these are the lines in the restorefromfile script that are causing the problem.

                if [ -d $TEMP_FOLDER/sql ]
            then
                find $TEMP_FOLDER/sql -type f -name 'sugar*' ! -name '*triggers*' -exec sh -c 'sql=${1:-:}; x="${2:-:}"; mv "$x" "$sql/sugar.sql"' bash "$TEMP_FOLDER/sql" {} +\;
                find $TEMP_FOLDER/sql -type f -name '*triggers*' -exec sh -c 'sql=${1:-:}; x="{}"; mv "${2:-:}" "$sql/sugar_triggers.sql"' bash "$TEMP_FOLDER/sql" {} +\;
            fi

    Because it is expected that they will create a sugar.sql file, but in the end the one that comes with the tar.gz file is left.

    The other problem is when I want to make a backup, the backup script tells me that the config.php file does not have a db_name, and I have already seen that this is the case because it is written in the config_override.php file.

    cat ./utilities/configs/config_override_dockerized.php >> ./data/app/sugar/config_override.php

    The backup script expects the following and does not find it in the config.php file.

    # checking db name if it is indeed sugar
            DB_NAME=`cat data/app/sugar/config.php | grep db_name | awk '{print $3}' | sed 's/[^[:alnum:]]//g'`

    I'm thinking of an improvement, which is that when restoring an oncloud backup, the database is sometimes very large due to data in tables that are not very important when inspecting a problem. Therefore, I suggest that a sed implementation be made to reduce the volume of data that we do not need when inspecting instances. It is something like this:

    sed -i.bak '/^\(INSERT INTO\)\( `pmse_bpm_flow`\)/d' sugar1320ent.sql;

    Have a great weekend, greetings.

Comment

  • Hi guys.

    Dear  I run the SugarDockerizer project on Arch Linux. I have had some problems with the script to restore oncloud backups. When I try to move the database to the mysql container, it always tells me that the database is corrupt.

    I believe these are the lines in the restorefromfile script that are causing the problem.

                if [ -d $TEMP_FOLDER/sql ]
            then
                find $TEMP_FOLDER/sql -type f -name 'sugar*' ! -name '*triggers*' -exec sh -c 'sql=${1:-:}; x="${2:-:}"; mv "$x" "$sql/sugar.sql"' bash "$TEMP_FOLDER/sql" {} +\;
                find $TEMP_FOLDER/sql -type f -name '*triggers*' -exec sh -c 'sql=${1:-:}; x="{}"; mv "${2:-:}" "$sql/sugar_triggers.sql"' bash "$TEMP_FOLDER/sql" {} +\;
            fi

    Because it is expected that they will create a sugar.sql file, but in the end the one that comes with the tar.gz file is left.

    The other problem is when I want to make a backup, the backup script tells me that the config.php file does not have a db_name, and I have already seen that this is the case because it is written in the config_override.php file.

    cat ./utilities/configs/config_override_dockerized.php >> ./data/app/sugar/config_override.php

    The backup script expects the following and does not find it in the config.php file.

    # checking db name if it is indeed sugar
            DB_NAME=`cat data/app/sugar/config.php | grep db_name | awk '{print $3}' | sed 's/[^[:alnum:]]//g'`

    I'm thinking of an improvement, which is that when restoring an oncloud backup, the database is sometimes very large due to data in tables that are not very important when inspecting a problem. Therefore, I suggest that a sed implementation be made to reduce the volume of data that we do not need when inspecting instances. It is something like this:

    sed -i.bak '/^\(INSERT INTO\)\( `pmse_bpm_flow`\)/d' sugar1320ent.sql;

    Have a great weekend, greetings.

Children